In order to allow a node to send signed messages to another node
the signingPresentation function can be called to make a
node2node presentation of signing preferences.
It is up to the sketch developer to make sure updated signing
preferences are communicated accordingly.
When activated, suspicious signing related activities will eventually
cause the node to lock down and transmit a I_LOCKED message to the
gateway at 30m intervals.
Unlocking is done by grounding a pin or erasing the EEPROM.
See Doxygen for details on use.
Fixes#280
In order to build core tests, there cannot be any hard coded
GATEWAY flags (like MY_GATEWAY_ESP8266). These needs to be set
in the sketch that implements the gateway.
These will automatically be built for every PR by Jenkins.
The test sketches in this commit evaluates signing (hard/soft) and
whitelisting (on/off). Full verbose signing debug is enabled.
RF24 radio is also enabled.
The message sender was retrieved from the message buffer after
prepareSigningPresentation() was called. This function resets
the message buffer so that is not the proper way to do it. Now,
the message sender is extracted first in signerProcessInternal()
in order to avoid the value being overwritten later on.
The Sha204Personalizer has been converted to a SecurityPersonalizer.
It takes care of generation and storage of keys and data to both
ATSHA204A and nonvolatile storage (EEPROM).
Library has been updated to read any software security related data
from the corresponding EEPROM locations.
The effect this has is that any node using any security feature has to
execute the personalizer at least once to store appropriate values.
The benefit of this is that the software no longer contain sensitive data
such as HMAC or AES keys.
Whitelists still are stored in software as they are variable in size.
Whitelisting is now supported by all nodes that support signing,
while only nodes that define a whitelist with
MY_SIGNING_NODE_WHITELISTING will check signatures against a whitelist.
This allows a single node in a network to have a whitelist without require
all nodes that communicate it to be configured for whitelisting. The node
will publish its whitelisting preferences to the gateway together with its
signing preferences. In other words; whitelisting is now working as signing
requirements does.
A node that use whitelisting will reject any message (signed or unsigned)
from nodes not present in its whitelist.
Fixes#279
Signing logic has now been centralized to MySigning.cpp in order to simplify
maintenance and debugging.
Debug prints have been extended and "demoted" to verbose level.
To get signing related debug info, MY_DEBUG_VERBOSE will need to be defined.
This fixes#278
Considering the magnitude of the delta between master and
development branch currently, 2.0.0-beta apperas to be a
more realistic version than 1.6.0-beta.
A node that does not support signing, still needs to inform the
gateway about this to make sure the gateway carries a valid signing
requirement table when a node Id that was requiering signing stops
doing this.
This fixes#286.
Project named "MySensors Library & Examples"
Index root is libraries/MySensors with recursive search
No LaTeX generation
Documentation/html added to .gitignore
libraries/MySensors/core/MyPrivateConfig.h.sample contain an example for
how private configuration data can be organized.
Rename that file to MyPrivateConfig.h and place it in the same folder
as the sketch you want to build and include it in order to add private
settings that you for various reasons do not want to store in git:
Make sure to place this include before
All MyPrivateConfig.h files are ignored by git.
Signing backend debugs are now controlled by the MY_DEBUG flag.
This also means that on serial gateways, signing related debug
messages are forwarded to the controller with the appropriate
MySensors header information.
* Secure actuator example now require signed messages by default
* Whitelisting config example in MyConfig.h now uses correct keywords
* keywords.txt updated with the actual whitelisting keyword
* Signing backends have improved debug output
- The type of backend is presented in Get and Put nonce functions
- The resulting signature is printed for both sender and receiver
* Fixed bug in soft signer (the untransmitted part of the nonce buffer was
not the same in both ends)
* The ATSHA personalizer is updated to use acceptable syntax for user provided
HMAC key
In some cases, SPIFlash driver hangs during initialization
because it reads data from the SPI backend. But if SPI backend
has not been initialized, this fails.
As a consequence, only one pin is currently suppored.
AddPin will not really add a new pin, just replace the configuration
of the existing pin.
The motivation for this limitation is that 'new' costs a lot of
program memory.
Whitelisting is enabled using MY_SECURE_NODE_WHITELISTING in MyConfig.h.
The whitelist is provided in backend constructors.
See the SecureActuator example for a typical usecase.
The SHA command is available in ATSHA204A variants of the chip
and can be used to calculate SHA256 digests of arbitrary data.
This enables us to strengthen the quality of the signatures by
salting signatures with node-specific data and improving the
quality of random data.
Various fixes and tweaks to permit a gateway to request
signatures from nodes.
The following messages will not be signed (nor verified):
* All signing-related handshake messages
* All ID-related handshake messages
* All ACKs
An important change is that the polarity for the signing request
flags stored in EEPROM has changed. '0' now means signing required.
This ensures that if the "ClearEepromConfig" sketch is executed,
signing requests will be turned off by default.
As a consequence, it is recommended to clear EEPROM if signing will
be used to ensure all nodes default to a non-signing state.
process() altered the message buffer pending signing when
called in sign() causing the wrong message to be sent to the
signing backend. This is resolved by copying the original
message before processing incoming messages to make sure
the original message is kept. After it is successfully signed,
it is copied back to its original location again.
Also, the old 'ack' message buffer is renamed to tmpMsg to
indicate its use as a temporary message buffer for various
purposes.
The sketch closely resembles the RelayActuator example.
The difference is that this sketch require gateway to sign
all messages addressed to the actuator.
The dummy signing driver backend is used. But with this commit all
framework logic for managing signed messages in the MySensors
ecosystem is implemented and enables more sophisticated signing
backends to be added later on.
For a sensor (or gateway) that require a gateway to send signed
messages to it, add 'true' as the fifth argument to 'begin'.
The gateway will automatically inform a node of it's signing
requirements as soon as it receivs the nodes signing preference.
It is important to understand that if the gateway require
signing, it will in this implementation only require signing from
nodes that require signing by the gateway.
If the sensor requires signing from another node on the network
which it communicates directly with, it needs to send 'true' in
an internal message of type I_REQUEST_SIGNING.
ATSHA204 emulated signing backend. The emulated ATSHA204
implementation offers pseudo random number generation and
HMAC-SHA256 authentication compatible with a "physical"
ATSHA204.
NOTE: Key is stored in clear text in the Arduino firmware.
Therefore, the use of this back-end could compromise the key
used in the signed message infrastructure if device is lost
and its memory dumped.
The seed for the random number generated is sampled from an
analog pin. The pin is set in MyConfig.h using RANDOMSEED_PIN.
The pin should be unconnected.
The key to use for HMAC calculations must match the key used by
other nodes this node will exchange signed messages with. The key
for ATSHA204 emulator is set in MyConfig.h using hmacKey.
Patrick Fallberg