Feature #617

Extend imrest APIs to support new pairing and registration methods

Added by Hammel 5 months ago. Updated 3 months ago.

Status:ClosedStart date:01 Apr 2018
Priority:ImmediateDue date:
Assignee:Hammel% Done:

100%

Category:Software
Target version:Iron Man - 002 - MVP
Severity:01 - Critical

Description

This is to allow Jarvis to connect to the server and submit requests via the imrest interface.

Associated revisions

Revision 2b3ded88
Added by Hammel 4 months ago

RM #617: Completed registration processing for Jarvis.
Added test mode directory.
Remove SSL keys/certs and https support.
Added init class to initialize system state.
Added monitor class to return monitor information.
Fix registration processing for Jarvis to match latest design (no SSL).

Revision 2b3ded88
Added by Hammel 4 months ago

RM #617: Completed registration processing for Jarvis.
Added test mode directory.
Remove SSL keys/certs and https support.
Added init class to initialize system state.
Added monitor class to return monitor information.
Fix registration processing for Jarvis to match latest design (no SSL).

Revision de0201fc
Added by Hammel 3 months ago

RM #617, RM #619, RM #620: Registration and encryption support.
Updated help message to reflect currect supported command line arguments.
Fix logging to properly dump objects and not just strings.
Added TRACE level to logging.
Prep for encryption processing.
Add unit test for imrest pairing with Jarvis.
Add monitor test support to test driver (server.sh).
Add verbosity level support to test driver.
Fix up REST server startup to setup and teardown test directories.
Note: unit tests are currently broken.

Revision de0201fc
Added by Hammel 3 months ago

RM #617, RM #619, RM #620: Registration and encryption support.
Updated help message to reflect currect supported command line arguments.
Fix logging to properly dump objects and not just strings.
Added TRACE level to logging.
Prep for encryption processing.
Add unit test for imrest pairing with Jarvis.
Add monitor test support to test driver (server.sh).
Add verbosity level support to test driver.
Fix up REST server startup to setup and teardown test directories.
Note: unit tests are currently broken.

Revision 45a88bbd
Added by Hammel 3 months ago

RM #617: Add support for decrypting messages from Jarvis.

Revision 45a88bbd
Added by Hammel 3 months ago

RM #617: Add support for decrypting messages from Jarvis.

History

#1 Updated by Hammel 4 months ago

  • Subject changed from Extend imwww APIs to support new pairing and registration methods to Extend imrest APIs to support new pairing and registration methods
  • Description updated (diff)
  • Status changed from New to In Progress
  • % Done changed from 0 to 30

Implemented but needs testing. The update is that the inbound message body has a UUID in JSON format, re: { uuid: <value> } that then becomes a filename under /etc/ironman/jarvis/<uuid>. Also supports the GET monitor API, including support in imwww to save a descriptor (re: Location) when configuring the monitor's networks.

#2 Updated by Hammel 4 months ago

Implementing SSL has become problematic, probably because I can't quite grasp all the nuances of getting it right (not to mention the problems of dealing with self-signed certs). But it also now seems like overkill. What I really want is the same process the sensors are using with the monitor:

  1. Exchange UUID key at registration: each monitor has a unique UUID and each Jarvis node has unique UUID.
  2. Encrypt a message with aes(UUID+IV+message).
  3. Send IV plus encrypted message in the clear (http, not https)
  4. Decrypt using UUID+IV

The UUID is never sent except in the registration so it's a low-probability of getting intercepted - the user has to enable registration. So while the message and IV are sent in the open, the message itself is encrypted. You can know who is talking but not what is being said. At least not easily.

This will simplify message passing considerably. It's probably hackable, but not easily. And even the hacking could be reduced by using a sneaker-net input of remote end point keys.

I need to implement this on both end points: monitor (imrest) and Jarvis.

#3 Updated by Hammel 3 months ago

  • % Done changed from 30 to 50

This has been implemented in Jarvis for decoding messages that were encrypted on on the NodeJS side. It's been shown to work by having Jarvis ask for /monitor, which returns the monitor descriptor using AES encryption inside a JSON packet that contains an IV and a message.

Since AES 128 is being used the encryption key (Jarvis' UUID) is shorted to 16 bytes on both ends.

This code is committed and pushed.

Now I need to reverse the process by encrypting in Jarvis and decrypting on the NodeJS side. This will be tested using the /device API from Jarvis to monitor.

#4 Updated by Hammel 3 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

Implemented, tested and pushed. Tested by having Jarvis request a device state change and having the monitor print out the state change request text.

Closing issue.

Also available in: Atom PDF