MY_SIGNING_SIMPLE_PASSWD is now
called MY_SECURITY_SIMPLE_PASSWD.
MY_SIGNING_SIMPLE_PASSWD only affects signing,
and a new flag, MY_ENCRYPTION_SIMPLE_PASSWD
only affects encryption.
MY_SECURITY_SIMPLE_PASSWD enable both these flags.
The rPi port has been improved to support more
security settings and it is now also possible to
enable encryption for RFM69 transport.
Documentation has been improved to provide a
"Security" section under "Library customisation"
which has a table that summarize all security
related configuration flags, and the corresponding
rPi configuration flags.
The signing personalization documentation has been
updated to include the procedure for rPi.
Fixes#1055
* Fix cppcheck issues
Fixes the following cppcheck issues:
examples/SecretKnockSensor/SecretKnockSensor.ino
305 variableScope 398 style
The scope of the variable 'timeDiff' can be reduced.
examples/SensebenderGatewaySerial/SensebenderGatewaySerial.ino
127 variableScope 398 style
The scope of the variable 'led_state' can be reduced.
* Doxygenize MyMessage / Message manipulation
This should replace the static documentation at
http://korturl.nu/stupid
I have enabled existing comments and added new comments where
necessary. Feedback on syntax and contents is welcome.
As discussed in
http://korturl.nu/gitler-is-a-stubborn-bastard-1
and numerous other forum threads, many people don't understand
that id generation is done by the controller.
Many new users start out their first MySensors network with a
gateway, a single sensor node and no controller. Since MySensors
defaults to AUTO node id, the node gets stuck on TSM:ID:FAIL,
like this:
TSM:ID
TSM:ID:REQ
TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
TSM:ID
TSM:ID:REQ
TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
TSM:ID
TSM:ID:REQ
TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
TSM:ID
TSM:ID:REQ
TSF:MSG:SEND,255-255-0-0,s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK:
!TSM:ID:FAIL
This change adds a clarifying note about the controller in the
doxygen documentation.
To use this feature, add the following to a sketch, for example
GatewayESP8266MQTTClient:
const uint8_t bssid[] = {0x00, 0xDE, 0xAD, 0xBE, 0xEF, 0x00};
#define MY_ESP8266_BSSID bssid
This feature was requested in
https://github.com/mysensors/MySensors/issues/947
* Added support for I2C EEPROM OTA
* EEPROM OTA now uses extEEPROM as driver
* Compiler warning fix
* Style check fixes
* Fix doxygen warnings of I2CEeprom
* Use bool instead of boolean in I2CEeprom shim
* Fix re-merged style problem
added variant of MyMessage::set and sendSketchInfo that accept a
string that's stored in PROGMEM.
This avoids the need to (temporarily) store strings in memory to get
them into a message.
- Fix UDP send
- Add a default value for MY_IP_GATEWAY_ADDRESS and
MY_IP_SUBNET_ADDRESS, making them optional when using MY_IP_ADDRESS
- Add support for MY_IP_GATEWAY_ADDRESS and MY_IP_SUBNET_ADDRESS to
W5100
* Sha256 driver cosmetics
cosmetic cleanups:
- use actual define that was used to allocate the array
- remove unused file globals
* Save memory by eliminating sha256_hash array
eliminated sha256_hash array to save memory. Instead pass the
Sha256Class result pointer.
There seems to be no use for the extra sha256_hash array as it was
zeroed exactly at the same time, the Sha256Class result was invalidated
(by calling signerSha256Init)
If the result needs to stay around while another sha is calculated,
it's better to have the user taking care of this.
* Moved hmac methods and buffers to separate class
This allows saving the buffer memory if no hmac is needed ... eg. with
the public Signing API.
For soft signing, let backend handle checksum verification of
personalization data. This ensures that the backends sha256 library is
used and avoids an unnecessary instanitation of the public library.
For atsha204 signing, no checksum verification is made, just chip
locking flags.
Fixes#872
* Signing support with MAX_PAYLOAD>32
Support in the signing backends to handle configurations
where MAX_PAYLOAD is more than 32 bytes.
Fixes#748
* Support big message signatures
Support for signing messages larger than 32 bytes.
This is not fully testable with the current version of
the library but the change would add theoretical support
for signing any sized messages.
Fixes#749
* Have gw properly indicate whitelisting preferences
If the gateway hold a signing whitelist, inform all
nodes of this requirement and not just nodes that hold
whitelists themselves.
Fixes#806
* Harden security
The flag MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL
has been removed. Gateway will now request signatures
from everyone by default.
In addition to this, no nodes in the network will allow
clearing of signing/whitelisting preferences by OTA
commands by default.
If the old behaviour is needed (suitable for gradual
signing roll out and development purposes) a new flag,
MY_SIGNING_WEAK_SECURITY can be set.
Fixes#807
* Signing debug messages rewritten
All signing related debug has been rewritten to
better match other core debug printouts.
Also, backends are updated to have a smaller
implementation delta.
* Simplified signing option implemented
Enable by MY_SIGNING_SIMPLE_PASSWD. Signing, and signing requirements
will be enabled, as will encryption. Whitelisting is optional.
The value provided to MY_SIGNING_SIMPLE_PASSWD is used as HMAC and AES
key. Whitelists use the first 8 bytes of the password and the ninth
byte from the node ID as serial.
Password is required to be at least 8 characters wide. It is zero
padded if it is not long enough to cover the AES (16 bytes) and HMAC
(32 bytes) keys. It is not recommended to have a password shorter than
32 bytes, and there is no need for a password longer than 32 bytes.
* Add documentation section for signing debug
* Add nRF5 encryption to simple signing option
* Restructure MySigning documentation
* Minor fixes for Linux
This commit changes the way random numbers are available
with MySensors.
The AVR platform uses a 32 Bit random seed build from a floating
analog pin. The way of the generation of this seed is FIPS 140-2
compliant.
For support MCU with a fast way to generate random data, the
hwGetentropy() command is now available to allow rapid generation
of random data.
The ESP8266 platform uses the internal random source for randomness
for hwGetentropy() and Arduino's random() function.
The NRF5 platform initializes the pseudo random number generator
from internal hardware number generator. The internal AES-ECB unit
generates random data after filling with HWRNG data by AES-CBC.
On Linux getrandom() is implemented via syscall().
signerAtsha204SoftGetNonce speed:
AVR = ~14000us (sha204Soft)
NRF51 = ~152us (AES-CBC), 1739us (old sha204Soft)
NRF52 = ~31us (AES-CBC), 183us (old sha204Soft)
ESP8266 = ~20us (RANDOM_REG32), 380us (old sha204Soft)
All Nonce results tested for FIPS 140-2 compliance successfully.
* Add NVRAM support
This is an EEPROM replacement based on MCU's internal Flash memory.
The NVRAM class is designed to be stateless. Each operation is
written to flash immediately.
The last 16k(nRF51)/32k(nRF52) of Flash memory are managed by the
VirtualPage class. This class allows writing a single emulated 4k
page up 40,000 times.
The NVRAM class is a log based byte-wise storage allowing up to
40,000,000 writes depending on the number of used addresses. Each
four allocated addresses from the beginning of the NVRAM reduce the
write log by one.
When first 256 bytes of the emulated storage are used, there is an
average writing capacity of 145,000 cycles per byte.
When the write log is full, the NVRAM is compressed into a new flash
page. After a new page is ready, the old page is released. This
process can take up to 4500 ms and cannot be interrupted.
The NVRAM functionality can easily be ported to ESP8266 or SAMD by
providing a Flash interface.
* Add NRF5 platform support
This is the support of the Nordic Semiconductor NRF51 (nrf51822,
nrf51422) and NRF52 (nrf52832) platform. Based on arduino-nRF5
(https://github.com/sandeepmistry/arduino-nRF5).
The included radio driver is compatible with the NRF24 devices.
Using a SoftDevice (BLE)is not supported and must be removed before
flashing MySensors with a "mass_erase" operation.
- use MY_SERIALDEVICE in hwInit
- disable use of MY_SERIALDEVICE.flush() since the current STM32duino
implementation performs a reset instead of an actual flush.
tekka
Patrick Fallberg
Mikael Falkvidd
Mikael Falkvidd git@mjo.se
d00616
Krister W
Rainer Clasen
Marcelo Aquino
freynder
Embedded Innovation