For atmega32U4-boards USBDevice.init(); must not be called. This is only necessary for SAMD-boards.
With this patch the library works fine with an arduino micro board.
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
Patrick Fallberg
Henrik Ekblad
Jan Chrillesen
tekka007
zaphodus
fleinze
mboyer85
Thomas Mørch
Ivan Kravets
Gert Sanders
Kolbi
Marco Noord