kristjanvj / tsense Goto Github PK

See code for key derivation / expansion in servers.

FOR POST DEMO PHASES:
Cleanup logging of authentication attempts and responses.

For post demo milestones

aes_crypt.h had "unroll_decrupt_loop" defined. This seems to have been a type 
and is now changed to "unroll_decrypt_loop". It should be verified that this 
works as intended on the Arduino.

Remove hard coded paths from sink and auth daemons.
Enhancement for post-demo milestone.

  ... the aes_constants file

Use new header file aes_tables.h instead of defining the AES lookup tables in 
code. See aes_crypt.*

Test tsensor data transfer protocol against server chain

Probably good idea to add a bit more entropy to the data transmission message. 

Possibilities:
1) Add a fairly small random number field to the message.
2) Implement an ack mechanism in which the sink responds with an encrypted next 
round nonce (counter or random) which will then be included in the next message.

Note that 2) would also be a pretty strong anti-replay mechanism as well as 
enable the sink to detect and handle missing messages.

As per emails from KR

Implement the FINISH message, post demo. 

Fix code. 

Move AES lookup tables into separate header -- common with rest of AES library.

Finish burning of rest of device info onto sensor.

The timer field in the protocol is too big, 2 bytes plenty.
Also, rename to something more descriptive such as key_renewal_interval.

FOR POST DEMO DEVELOPMENT

Replace the mysql code with some db agnostic C++ API.

The tsensor is supposed to be reset by a finish message from the client on 
client shutdown. The message is delivered and apparently resets the sensor to 
standby state. However, re-launching the client fails to restart the sensor 
properly. 

To recreate:
1) Start the client. The sensor initializes and starts data transfer.
2) Stop the client. The sensor is reset (ack returned and ready LED blinks)
3) Start the client. The sensor hangs in handling session key delivery.

gracefully close listener sockets.

..

implementation. Depends on protocol development.

Finish the documentation of the code in doxygen format. 
Generate and post on-line documentation.

This enables tsensor to do two checks on the authenticity of the authentication 
server.

A small command line C++ program using /dev/urandom etc to generate keys and 
write to console.

Sink needs the device ID to look up the encryption key.
Keep the current device in the encrypted part of the packet for verification.

The do-nothing unroll in the decrypt needs to be removed or the unrolling 
implemented. Problem: If unrolling is defined in, then decrypt does nothing.

Update the tsconfig utility to program the EEPROM with key derivation constants.

print to syslog

Implement command line input of listen port and peer addr port info.
ONLY FOR POST DEMO MILESTONE

Problem: We want this code to work on arduino which has slim to none support 
for new / delete.

Validate the id message on reception. plaintext pID and deciphered must match.

 ..

Use globals burned into EEPROM

We need to implement the periodic re-keying -- the refreshing of the transport 
encryption and MAC keys. 

Can be hardcoded in prototype. Sensor ids and corresponding K_AT listed on wiki.

The auth server needs to have some form of sink server profile list it uses to 
store vital sink server statistics.

Why required? More convenient to calculate padding (if needed) in the 
CBCEncrypt function itself.

Update the protocol documentation.

Need to clarify the various message codes, e.g. the difference between 
REKEY_REQUEST and REKEY_HANDSHAKE.

Diagram would be nice, e.g. KR's

HOLD FOR CURRENT -- IMPLEMENT POST DEMO.

Several issues need to be addressed in the protocol (pack/unpack) methods, main 
points below:

1. create one struct per message type which makes the protocol much more 
transparent, almost self-documenting.

2. Allocate the proper number of bytes in message struct -- no pointers!

3. Error handling must be an integral part of the next protocol.

The random number delivered should be a key sized 128-bit number. 16-bits 
weakens security. Priority low in this phase. Fix later.

... as discussed in email

FOR POST DEMO PHASES:
store the sensor id info received -- id and nonce. Check nonces for freshness 
to prevent replays.

Test tsensor implementation of the authentication protocol against the server 
chain

Define constants for key derivation in a common header file. 
See TlsAuthServer, tsensor.

Occasionally a byte is missing somewhere in the transmission buffer from sensor 
to client. This leads to corruption of the following message -- usually the 
message type code will be wrong and the current client simply aborts.

Thoughts:
* Check the serial.write method on the arduino.
* Add a CRC or a simple checksum to catch errors?
* Implement more graceful error recovery in the client?

Priority low to hold for now. 

Occasional stack smashing in sink server. Have not traced the origin of the 
error. tls_sinkserver.cpp version r303