1. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security Requirements for 802.15.3] Date Submitted: [9 October, 2001] Source: [Ari Singer, Principal Engineer] Company [NTRU] Address [5 Burlington Woods] Voice:[(781) 418-2500], FAX: [(781) 418-2532], E-Mail:[asinger@ntru.com] Re: [Doc. IEEE 802.15-01/054r0, Doc. IEEE 802.11/00-362, Draft P802.15.3/D0.5] Abstract:[This presentation represents NTRU’s proposal for the process of creating the P802.15.3 Security clause for the standard.] Purpose:[To provide requirements and process discussion for 802.15.3’s MAC Security clause] Notice:This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 2 Goals of this Presentation Review basics of security solutions Discuss security methodology Agree on security problems that need to be addressed Explore various security requirements Discuss characteristics of cryptographic solutions Discuss plans for development of security solutions for 802.15.3

3. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 3 Outline Security Foundations Arriving at Security Requirements for 802.15.3 Public-Key and Symmetric Key Cryptography

4. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 4 Primary Security Services Assurance that the data has not been modified since it was sent. Assurance that only the sender and recipient are able to read the data. Assurance that the entity with whom one is communicating is the correct entity. Authentication Confidentiality Integrity

5. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 5 Cryptographic Security Methods Challenge & Response Signing & Verifying Encryption & Decryption Key Agreement Encryptor uses a cryptographic key to scramble the data so that it can only be read by the holder of the decryption key (confidentiality). Signer uses a cryptographic key to demonstrate knowledge of a secret to a verifier while binding that knowledge to specific data (authentication / integrity). Challenger sends data for the responder to use to demonstrate knowledge of a secret (authentication). Two parties communicate in a manner so that only those two parties have knowledge of a secret.

6. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 6 Requirements Derivation Process Identify Assets What are we protecting? 1 What does the system do? What are the constraints? Identify Environment2 Who is allowed to do what with the assets? Define Access Control Policy 3 Who might break the rules? Identify Threat Agents4 How can the threat agents break the ACP? Identify Threats5 What needs to happen to mitigate the threats? Derive Security Objectives6 What mechanisms need to satisfy the security objectives and environmental constraints? Generate Security Requirements 7 Review each step with knowledge of later choices. Did we make good choices? Is it feasible and useful? Review8

7. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 7 Sound Design Principles Simplicity – Don’t do more than is necessary and keep it simple! Flexibility for multiple use cases – but find commonalities! –Selectable Security Services No Security Services Confidentiality Only Integrity Only Confidentiality and Integrity –Authentication when needed No Authentication Initiator Authentication Responder Authentication Mutual Authentication Separation of Key Management and Session Security

8. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 8 Non-Security Considerations How much extra will adding security cost for manufacturing? What about infrastructure? Maintenance? Will the security impact the data transfer rate? Will it consume too much battery power? Is the security implementation consumer friendly? Does the security enable all desired use cases? Will the security solution work for a large number of devices? Will all devices be able to communicate securely with each other? What other standards must the security solution comply with? (e.g. will it be the same for 802.11? 802.15.1?) Monetary Cost Performance User Experience Scalability Interoperability Co-ordination

9. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 9 Past Problems with WEP Improper combination and use of cryptographic techniques –Used stream cipher with integrity check that allowed for blind modification –Did not provide enough protection against collisions, which breaks the security of stream ciphers –Bad luck that the particular cipher had a security weakness Did not receive proper amount of scrutiny from security experts Compromised security too much to satisfy other requirements

10. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 10 Outline Security Foundations Arriving at Security Requirements for 802.15.3 Public-Key and Symmetric Key Cryptography

11. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 11 Assets: What Are We Protecting? Transmitted Data –Audio Stream –Video Stream –Personal Data –Public Data Cryptographic Keys User Passwords Other?

12. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 12 Environment: What Devices Will Use 802.15.3? Computers PDA/HPCs Printers Set-top boxes Information Kiosks Image Display Devices Video Games Digital Cameras Stereos

13. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 13 Environment: What Will 802.15.3 Be Used For? Video Games – Controller  Console  Television Media Distribution – DVD/Set Top Box  Monitor/TV Data Transfer – High Speed Connection from Computer  PDA Stereo – Media Transmission from Stereo  Speakers Video Camera – Baby Monitor  TV/Monitor/Speakers Medical Sensor – Sensor  Alarm/Transmission Node

14. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 14 Environmental Constraints: What Can’t We Do? Low power consumption High speed Inexpensive

15. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 15 Access Control Policy: Who Should Be Able to do What? Legitimate monitor/TV/speakers should be able to obtain the data from the source Legitimate PDA/HPC should be able to transfer data with computer Data should not be read by any device that does not have “internal” access No external device should be able to modify legitimate traffic without detection

16. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 16 Threat Agents: Who Are We Protecting Against? Un-trusted devices Pirates Hackers Nearby wireless users Legitimate users

17. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 17 Threats: What Might the Threat Agents Do? Pirate copyrighted digital content Intercept secret information Send forged messages Modify legitimate messages

18. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 18 Security Objectives Piracy Protection –Provide confidentiality of content between legitimate output devices (speakers, monitors, etc.) and data source –Provide authentication for output devices before transmitting data Secret Data Transfer Protection –Provide confidentiality for data transfers –Provide authentication for data receiver before transmitting data Prevent Insertion of Illegitimate Data –Perform integrity checks on received data –Provide authentication for date sender before accepting data Modify Legitimate Messages –Provide integrity checks on received data

19. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 19 Security Requirements Security requirements will depend on all of the previous steps Some additional questions: –Are devices going to be individually identified or authenticated based on role? –Can security states be maintained in a session or are all communications atomic? –What are the constraints on packet size and packet expansion? –Will we only allow password based key initialization (easy user experience)? –Do we need an identical solution to other standards? –Do we want selectable security levels? –Do we need all of the security services for these applications?

20. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 20 Outline Security Foundations Arriving at Security Requirements for 802.15.3 Public-Key and Symmetric Key Cryptography

21. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 21 Public-Key vs. Symmetric Key Cryptography Secret is never removed from device Key is associated with a single identity Usually used for key encryption and source authentication Greater message expansion Slower and consumes more power Secret must be communicated between two devices Key is associated with a relationship Usually used for data encryption and data integrity Less message expansion Faster and consumes less power Public-Key Symmetric Key

22. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 22 Security Setup: Key Distribution Key generation inside each device Public key may be sent over public channels and stored in clear Public key is authenticated by trusted third party signature or authenticated contact with recipient Key generation inside a single device Key must be sent over private channel and stored in private memory Key is authenticated by authenticated contact with recipient (often via public-key) Public-Key Symmetric Key

23. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 23 Security Maintenance: Key Management Need integrity protected memory Limited storage required Keys may expire or be revoked Keys are usually long term Need privacy and integrity protected memory Must store key for each group association Keys may be removed Keys are usually short term Public-Key Symmetric Key

24. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 24 Security Services: Authentication and Integrity Digital signature Uniquely identifies signer Provides data integrity Provides authentication information to anyone with public key Larger signature Message Authentication Code Identifies group membership Provides data integrity Provides authentication information to anyone in the group Smaller MAC Public-Key Symmetric Key

25. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 25 Security Services: Confidentiality Encryption Single recipient Allows for forward secrecy Encryption Group can be recipients No forward secrecy Public-KeySymmetric Key

26. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 26 Hybrid Security is Optimal Use public-key cryptography for key distribution Use public-key cryptography for key management Use symmetric key cryptography for bulk encryption and packet authentication

27. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 27 Next Steps Agree on actual security needs Formalize security goals Formalize constraints Provide a proposal for security requirements Define a timeline What else do we need to do?

28. October, 2001 doc:.: 802.15-01/487r0 Ari Singer, NTRU 28 Contact Information Ari Singer Principal Engineer NTRU asinger@ntru.com