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.
Henrik Ekblad
Patrick Fallberg
Marcelo Aquino