90 likes | 183 Vues
Explore communication relationships, security threats, and services in TLS implementations for smart objects. Learn about RFC 4101 and RFC 3552 recommendations for writing protocol models and security considerations. Discover TLS's flexibility, authentication, key exchange protocols, and session resumption. Consider various credentials, algorithms, and key validation techniques for data protection. Lower footprint may impact functionality and dependencies. Code compiled under Ubuntu Linux.
E N D
Small(er) Footprint for TLS Implementations Hannes Tschofenig Smart Object Security workshop, March 2012, Paris
How do the communication relationships look like? For example: Does your smart object talk to only a small set of pre-defined servers?
Following the recommendations in RFC 4101 “Writing Protocol Models” helps to make these important design aspect transparent.
What security threats do you care about? What security services do you have to offer?
RFC 3552“Guidelines for Writing RFC Text on Security Considerations” offers valuable guidance.
TLS (or DTLS) may be the right building block for your problem; it also offers a lot of flexibility. Different credentials (pre-shared secrets, passwords, asymmetric crypto, etc.) Various authentication and key exchange protocols Numerous algorithms for usage with data traffic protection Session Resumption (with and without server-side state) Alternative key validation techniques Possibility to replace record layer
Unfortunately, there is no magic! Lower footprint means fewer functions or more dependencies/assumptions
Note: The code was compiled under Ubuntu Linux using the -Os compiler flag setting for a 64- bit AMD machine.