Messaging Protocols: Difference between revisions
Jump to navigation
Jump to search
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
===Candidate Protocols for Messaging and Encapsulation=== | ===Candidate Protocols for Messaging and Encapsulation=== | ||
====Low-level | ====Low-level Signaling==== | ||
The purpose of the low-level protocol is to provide primatives such as: | |||
*Message Encapsulation appropriate for different mediums | |||
**RS-232 | |||
**RS-485 | |||
**Ethernet | |||
**SMS/Cellular | |||
*Polling, and unique identification protocol | |||
**Uniquely identify all devices on the network | |||
**Handle collisions | |||
=====Protocol Candidates===== | |||
* [http://www.modbus.org MODBUS - Industrial Control protocol, works over serial or Ethernet] | * [http://www.modbus.org MODBUS - Industrial Control protocol, works over serial or Ethernet] | ||
** [http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf MODBUS over Serial] | ** [http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf MODBUS over Serial] | ||
====End to end session protocol==== | |||
The session protocol is responsible for ensuring message fidelity, security and standardizing the protocol for 2-way transactions. | |||
=====Considerations===== | |||
*Ideally, session is encrypted and authenticated at all levels | |||
**User should know they are interacting with a legitimate terminal | |||
**Token should know that it is talking to a legitimate reader | |||
**Reader should not leak any secrets during transaction | |||
**Secrets should not be subject to interception between reader and server/panel | |||
***Physically secure wiring/network | |||
***Secure/encrypted protocols | |||
*Messages should be not be able to vulnerable to session replay | |||
**Time stamping/serializing of messages | |||
*Messages should not be subject to intentional or accidental alteration in transit | |||
**Message CRC and cryptographic signing/MAC protocol | |||
=====Protocols and Session Flow===== | =====Protocols and Session Flow===== | ||
*[[Example Message Flow]] | *[[Example Message Flow]] | ||
*[[Open Source Access Control Messaging Standard]] | |||
====Protocol Examples and White Papers==== | |||
*[http://www.autoidlabs.org/uploads/media/AUTOIDLABS-WP-HARDWARE-048.pdf A Mutual Authentication Protocol for RFID Using IDEA] | |||
*[http://csrc.nist.gov/publications/nistpubs/800-98/SP800-98_RFID-2007.pdf NIST Guidelines for Securing RFID] | |||
*[https://www.cdt.org/privacy/20060501rfid-best-practices.php CDT Privacy Best Practices for Deployment of RFID Technology] | |||
Latest revision as of 10:35, 28 June 2012
Candidate Protocols for Messaging and Encapsulation
Low-level Signaling
The purpose of the low-level protocol is to provide primatives such as:
- Message Encapsulation appropriate for different mediums
- RS-232
- RS-485
- Ethernet
- SMS/Cellular
- Polling, and unique identification protocol
- Uniquely identify all devices on the network
- Handle collisions
Protocol Candidates
End to end session protocol
The session protocol is responsible for ensuring message fidelity, security and standardizing the protocol for 2-way transactions.
Considerations
- Ideally, session is encrypted and authenticated at all levels
- User should know they are interacting with a legitimate terminal
- Token should know that it is talking to a legitimate reader
- Reader should not leak any secrets during transaction
- Secrets should not be subject to interception between reader and server/panel
- Physically secure wiring/network
- Secure/encrypted protocols
- Messages should be not be able to vulnerable to session replay
- Time stamping/serializing of messages
- Messages should not be subject to intentional or accidental alteration in transit
- Message CRC and cryptographic signing/MAC protocol