This sketch is used to personalize the ATSHA204 crypto
circuit.
This is required in order to use the device for secure
communication.
The sketch also supports random key generation.
To personalize a ATSHA204 device, do the following:
1. Ensure the correct pin is used for the ATSHA204.
2. Execute the sketch without other changes to verify
that it can communicate properly with the device.
3g. For a device used in a gateway:
Enable LOCK_CONFIGURATION to lock the configuration
and enable random key generation as well as key storage.
4g. Execute the sketch to lock the configuration and obtain
a unique key. Be sure to note down the key printed in the
UART log as it has been stored in the chip and will never
be accessible again (a new key is calculated on subsequent
runs).
The key can still be changed.
5g. Enable SKIP_KEY_STORAGE to prevent generating new random
keys on sketch re-execution.
3n. For a device used as a node:
Enable USER_KEY_DATA and enter your private key data
in user_key_data.
Then enable LOCK_CONFIGURATION to lock the configuration
4n. Execute the sketch to lock the configuration and store
the user-supplied key.
5n. Optionally: Enable SKIP_KEY_STORAGE to prevent re-writing
the user supplied key on sketch re-execution.
6. Optionally: Enable LOCK_DATA to prevent the key to be
changed.
Locking operations are recommended to include CRC
and since sha204 library internally carries the proper
algorithm for this, it has now been refactored to support
both static and incremental calculations needed for both
command marchalling and locking.
MySensors will have native support for sha204 and the
source for usage and personalization of sha204 will be
much more elaborate than this example so it does not
provide additional understanding for the chip.
Taken from the sha204_library folder in
https://github.com/jimblom/sha204-Breakout
Commit 8e1ac05ef987b1869605ad067db2bdbaec1c109f
ATSHA204 is a crypto cirquit from Atmel that enables
SHA256-based MAC and HMAC calculations as well as
secure key storage and random number generation.
This can be used to sign messages passed between
sensor nodes and prevent both man-in-the-middle and
replay attacking.
Even thouh auto ack was enabled we still called
RF24::writeAckPayload(pipe,&pipe, 1 ); after reading a message.
This probably caused radio to misbehave.
Upgraded RF24 to latest version which supports SoftSPI.
Added DigitalIO and UTFT libraries to support the new example.
Fix problem reported in RelayWithButtonActuator example.
Adjusted all Gateway examples but only one sensor example so far
(DallasTemperature). Other sensor examples should get the same three
lines added (not mandatory but helps avoiding unnecessary debugging when
selecting the wrong setup)
Retry parent node search with each transmit when parent has not been
found.
Transmit does not block on transmit when no parent has been found as
this depletes batteries on battery powered nodes.
Fix nRF24 configuration for dynamic ACK's. This bug caused broadcasts to
be sent with auto-ACK's.
To not break existing functionality parent search can be started when
node ID is still unknown. In this case node ID is set to broadcast ID,
which can cause funky stuff to happen...
Patrick Fallberg
Henrik Ekblad
Frank Olaf Sem-Jacobsen
ToSa27
Yveaux