kristjanvj / tsense Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/tsense
Automatically exported from code.google.com/p/tsense
Trusted Sensors research project. GPL v3
See code for key derivation / expansion in servers.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 10:23
FOR POST DEMO PHASES:
Cleanup logging of authentication attempts and responses.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 8:34
For post demo milestones
Original issue reported on code.google.com by [email protected]
on 8 Sep 2010 at 11:21
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 4:08
Remove hard coded paths from sink and auth daemons.
Enhancement for post-demo milestone.
Original issue reported on code.google.com by [email protected]
on 6 Sep 2010 at 11:39
... the aes_constants file
Original issue reported on code.google.com by [email protected]
on 6 Sep 2010 at 1:23
Use new header file aes_tables.h instead of defining the AES lookup tables in
code. See aes_crypt.*
Original issue reported on code.google.com by [email protected]
on 29 Aug 2010 at 11:22
Test tsensor data transfer protocol against server chain
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 12:56
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.
Original issue reported on code.google.com by [email protected]
on 13 Sep 2010 at 10:35
As per emails from KR
Original issue reported on code.google.com by [email protected]
on 5 Sep 2010 at 1:59
Implement the FINISH message, post demo.
Original issue reported on code.google.com by [email protected]
on 16 Sep 2010 at 3:51
Fix code.
Move AES lookup tables into separate header -- common with rest of AES library.
Finish burning of rest of device info onto sensor.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 10:37
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
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 2:06
Replace the mysql code with some db agnostic C++ API.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 11:47
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.
Original issue reported on code.google.com by [email protected]
on 14 Sep 2010 at 2:36
gracefully close listener sockets.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 12:22
..
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 10:25
implementation. Depends on protocol development.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 12:58
Finish the documentation of the code in doxygen format.
Generate and post on-line documentation.
Original issue reported on code.google.com by [email protected]
on 17 Sep 2010 at 2:26
This enables tsensor to do two checks on the authenticity of the authentication
server.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 9:30
A small command line C++ program using /dev/urandom etc to generate keys and
write to console.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 10:39
Sink needs the device ID to look up the encryption key.
Keep the current device in the encrypted part of the packet for verification.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2010 at 11:20
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.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 3:49
Update the tsconfig utility to program the EEPROM with key derivation constants.
Original issue reported on code.google.com by [email protected]
on 29 Aug 2010 at 11:23
print to syslog
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 10:24
Implement command line input of listen port and peer addr port info.
ONLY FOR POST DEMO MILESTONE
Original issue reported on code.google.com by [email protected]
on 6 Sep 2010 at 11:40
Problem: We want this code to work on arduino which has slim to none support
for new / delete.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 10:16
Validate the id message on reception. plaintext pID and deciphered must match.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 12:08
..
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 10:37
Use globals burned into EEPROM
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 9:54
We need to implement the periodic re-keying -- the refreshing of the transport
encryption and MAC keys.
Original issue reported on code.google.com by [email protected]
on 10 Sep 2010 at 12:10
Can be hardcoded in prototype. Sensor ids and corresponding K_AT listed on wiki.
Original issue reported on code.google.com by [email protected]
on 6 Sep 2010 at 1:21
The auth server needs to have some form of sink server profile list it uses to
store vital sink server statistics.
Original issue reported on code.google.com by [email protected]
on 9 Sep 2010 at 11:46
Why required? More convenient to calculate padding (if needed) in the
CBCEncrypt function itself.
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 2:08
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
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 3:22
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.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 1:36
The random number delivered should be a key sized 128-bit number. 16-bits
weakens security. Priority low in this phase. Fix later.
Original issue reported on code.google.com by [email protected]
on 4 Sep 2010 at 8:23
... as discussed in email
Original issue reported on code.google.com by [email protected]
on 27 Aug 2010 at 11:33
FOR POST DEMO PHASES:
store the sensor id info received -- id and nonce. Check nonces for freshness
to prevent replays.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2010 at 8:32
Test tsensor implementation of the authentication protocol against the server
chain
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 12:56
Define constants for key derivation in a common header file.
See TlsAuthServer, tsensor.
Original issue reported on code.google.com by [email protected]
on 24 Aug 2010 at 9:50
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.
Original issue reported on code.google.com by [email protected]
on 13 Sep 2010 at 10:29
Occasional stack smashing in sink server. Have not traced the origin of the
error. tls_sinkserver.cpp version r303
Original issue reported on code.google.com by [email protected]
on 13 Sep 2010 at 5:24
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.