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.
Default SDA pin is A3 for single wire communication.
The pin is selected in MyConfig.h.
I2C variant of ATSHA204 is not supported.
Messages are signed using HMAC-SHA256 where some parts of the
message digest are ATSHA204 specific.
The dummy signing driver implements the most rudimentary form of
signing. No pre-shared key is used, nonce is simply incremeted
each turn and signature is only calculated on the fist byte using
data XOR nonce.
This driver is intended for library debugging and sensor network
integrity verification (signed messages will force the radio to
transmit all 32 bytes of data).
It does check SIGNING_IDENTIFIER byte to avoid illegal mixing of
signing backends in the network (as seen by this node) and it does
verify proper execution order on the API.
The dummy driver rejects all other signing backend protocols.
Signing backend is selected in MyConfig.h
The signing driver framework resembles the radio driver framework
in the sense that it relies on MyConfig.h for driver specific
settings. This allows the constructor to be clean and the API less
likely to need change.
The API is designed with function pairs for sender and receiver of
a signed message.
The sender of a signed message uses putNonce() and signMsg()
and the receiver of a signed message uses getNonce() and
verifyMsg().
In addition, receiver is expected to call checkTimer() at regular
intervals to make sure the message session does not time out.
The program flow is that the sender transmit, after determining
that the message needs signing, a request to the receiver for a
nonce (I_GET_NONCE). The receiver calls getNonce() to obtain a
nonce and transmits the nonce back to the sender
(I_GET_NONCE_RESPONSE).
The sender stores the received nonce in the driver with putNonce()
and then calls signMsg() to sign the message to be transmitted.
The receiver then calls verifyMsg() to authenticate the signed
message using the nonce transmitted earlier.
The flow is described below:
---------------- -------- ---------- ------------------
|senders driver| |sender| |receiver| |receivers driver|
---------------- -------- ---------- ------------------
| | I_GET_NONCE | getNonce() |
| |------------------->|------------->|
| | | |
| setNonce() |I_GET_NONCE_RESPONSE| |
|<-----------|<-------------------|<-------------|
| signMsg() | | |
|<-----------| | verifyMsg() |
|----------->|------------------->|------------->|
| | | OK / not OK |
| | |<-------------|
It is expected that all signing schemes is built upon this
principle.
One bit in the protocol version field is converted to a sign
indicator. '1' means the message carries a signature in the
unused part of the payload data buffer.
Three new internal message types have been defined:
* I_REQUEST_SIGNING carries a boolean and is used to exchange
signing requirement information between
nodes.
If the I_REQUEST_SIGNING carries 'true'
the receiver is informed that the sender
require properly signed messages in order
to be able to accept the messages.
* I_GET_NONCE is passed from sender to a receiver that
require signing tellig it to submit a
cryptographic 'nonce' that the sender needs
in order to be able to sign the message it
intend to send. The I_GET_NONCE carries no
payload.
* I_GET_NONCE_RESPONSE is sent by the receiver of a signed
message in response to I_GET_NONCE.
The first byte of the payload is a signing
identifier informing the sender of the
signed message about the type of signature
the receiver is expecting.
Patrick Fallberg
Henrik Ekblad
Marcelo Aquino