Requirement

Before integrating LEDs I have to revise the communication protocol since the necessary information was not present before. Furthermore some properties are missing. The protocol should be:

• Future proof
• Secure
• Safe against transmission errors / modified communication

Following information was not present in the previous protocol:

• Key status changes
• LED status

LED status will be changeable by the client.

Message Protocol

This is the specification of the version 1 of the communication protocol. The previous (version 0) is obsolete an won't be used anymore.

For the encryption mode used (CBC), an initialization vector (IV) is needed. To successfully decrypt the IV has to be known by the clients. It is sent before the message:

<random IV><encrypted message>

Where the message is of the format shown in the table below.

The message consists of two 128 bit blocks where the unused bytes in the first block are filled with random numbers. The block length of 128 bits resembles the block length of AES which works is independent of the key length. Therefore this choice makes sense but is not a requirement since AES does automatic padding. The second Block contains the color and brightness values for the (max) 8 LEDs. Each is represented as a 4 bit for each component (RGB) and brightens value. This should be enough accuracy since the LEDs are used for signaling and the colors should be distinguishable. More values will result in many indistinguishable colors.

The time field contains the lowest 16 bit of the JavaScritpt getTime() which is defined as the number of milliseconds between midnight of January 1, 1970.

Messages can be sent in both directions client -> server and server -> client. The server ignores everything but the RGBL data in the second block. This is used to set the color of the LEDs.

Since push message is sent to every registered cloud service client the sender may also receive the message. The client or server can detect this by comparing the whole received message against the most recent sent and then silently discard the duplicate message.

Status Update Message

Status updates are sent by the server on status changes. To disguise the time of actual changes to an external observer status updates are sent in random periods. The extraneous updates can be identified by a Key Status Changed field containing only zeros. The client is expected to silently discard this message.

On server start it does not have any previous status thus it will send an status update message with set all bits of the Key Status Changed field to one. The client may report this event as server restart and must update the status to the values sent by the server.

If the client restarts it sends a message with all color values set to 0 and all brightness values to the maximum to signal the status update request. The server will answer this with a status update as described below.

Color Change Message

Color change messages are status update messages sent by the client. The server will ignore all values but the color values. Color values where the R, G and B components are all zeros are ignored. After changing the color values according to the message the server sends a status update.

When the client restarts it sends a color change message with the color values set to 0 and the brightness to the maximum. This message does not result in any colors to be changed but the status update is sent.

Forward Compatibility

To make to protocol future proof I have to add at least forward compatibility.

From Wikipedia:

Forward compatibility is the ability of a design to gracefully accept input intended for later versions of itself. The concept can be applied to entire systems, electrical interfaces, telecommunicationsignals, data communication protocols, file formats, and computer programming languages. A standard supports forward compatibility if older product versions can receive, read, view, play or execute the new standard gracefully, perhaps without supporting all new features.

To achieve this I include a 4 bit protocol version information and a 4 bit message length. The message length will be in 128 bit blocks - 1 which allows a maximum size of 256 blocks or 4 k bytes. Future client versions which expect more data should add that on the end, the current client will read (length) blocks but ignores everything after the second one. Alternatively future protocol versions can use the random padding for information since the version 1 client will ignore the content.

Otherwise the communication does not depend on a specific transport protocol, as it is implemented now it can support any messaging app with interface to tasker with minimal changes.

Security

The easiest mode of operation for a block cipher is electronic code book (ECB). But please erase that from your mind, your scratch book and everywhere else since it is not secure. For example see the following image encrypted using ECB:

(Image by Larry Ewing lewing@isc.tamu.edu, and The GIMP  )

The original Image could easily be guessed, right?

The easiest secure mode is cipher block chaining (CBC). But as always carefully select the parameters involved according to your application. Using the same key and IV on repeating messages with CBC has the same effect as above. The blocks are encrypted to the same cipher text and therefore produce a repeating pattern. Therefore a random IV has to be used. This can be sent in the clear since it is not part of the key. The time and random padding in the middle of the first block serves as additional variation in the message.

Error Detection

To detect transmission errors or packet manipulation I simply check if the magic number at the beginning of the 1st packet is correct. Since one bit error in the encrypted packet will be distributed over the whole clear text this should be enough to serve as a indication of change. The magic number is the binary representation of the ASCII letters "CR". If a packet with a different magic number is received the packet is silently discarded.