Example Message Flow

From ACCX Products Wiki
Revision as of 23:56, 25 November 2011 by Arclight (talk | contribs) (→‎Message Transaction Flow)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Message Transaction Flow

1. When a 13.56Mhz token is read, the reader (or more likely the microcontroller attached to it) generates a time-stamped and (random) serialized packet. The packet format contains the node and door/reader IDs and a message with the card serial number. Copies of the node ID and (optional) destination are contained in a clear-text header. The payload is encrypted using AES128 and a key unique to that reader.

2. If the "card" is a smart phone with NFC, then the payload also contains an encrypted message sent from the phone during the NFC exchange, which has a time stamp and a (random) serial number as well.

3. An 'ACK' message is sent to the reader once the message has been received by the server.

4. Once received, the message payload is decrypted using a unique key for that reader, loaded up from the data base.

If the message:

   a. Decrypts with the correct reader's key and
   b. the access rules allow access and
   c. the message in the payload from the phone also decrypts using a key unique to that phone/user then"

5. A message to the phone with an acknowledgment and any message we wish to pass to the user's screen is created and encrypted and added to the payload to be sent to the reader.

6. The response message is sent to the reader and decrypted. The command contained in the response is followed and the user is

 a. Allowed access or
 b. Denied access
 c. Optionally passed an encrypted message back from the payload.

The minimum payload appears to be 84-100bytes, more if we make the messages longer. This would also fit into a 160-byte SMS message, which could make GSM access easier.