1. doc.: IEEE 802.19-10/0098r0 Submission July 2010 Alex Reznik, et. al. (InterDigital)Slide 1 802.19.1 Security Procedures Notice: This document has been prepared to assist IEEE 802.19. 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. Date: 2010-07-12 Authors:

2. doc.: IEEE 802.19-10/0098r0 Submission Abstract We propose a set of security procedures for 802.19.1 –Address SDD Requirement –Consistent with our concept of operation Presented in contribution 19-10-0098 July 2010 Alex Reznik, et. al. (InterDigital)Slide 2

3. doc.: IEEE 802.19-10/0098r0 Submission 802.19.1 Concept of Operation Necessary Procedures –Discovery –Access Control –Policy Negotiation –Policy Enforcement Normal Operations –May also include policy updates and changes –Includes all other coexistence mechanisms July 2010 Alex Reznik, et. al. (InterDigital)Slide 3

4. doc.: IEEE 802.19-10/0098r0 Submission Where is Security Required Access (request to join) –Authentication and access negotiation Policy commitment (and de-commitment) –Needs to include “proof” that policies will be followed All exchanges –Needs standard integrity/confidentiality protection –Can leverage mechanisms provided by the transport means used –Not discussed here anymore July 2010 Alex Reznik, et. al. (InterDigital)Slide 4

5. doc.: IEEE 802.19-10/0098r0 Submission Authentication Procedures Centralized architectures –Can use standard approaches (e.g. 802.1X) –CDIS is the natural entity to provide authentication server Distributed architectures –Leverage the fact that every “master” device needs to authenticate itself to the TVWS Database. –Use TVWS DB identity to provide proof of successful authentication to the TVWS DB –Can use the same for centralized architectures as well Avoids the need to have authentication server in the CDIS –Doing this will require the use of Trusted Environments (TEs) July 2010 Alex Reznik, et. al. (InterDigital)Slide 5

6. doc.: IEEE 802.19-10/0098r0 Submission Trust Establishment What is it? –Measurement of the trustworthiness of the functionality in the New Entrant to “behave in an expected manner” How is it achieved? –Perform internal self check of the trust state of the New Entrant HW and SW self check based upon integrity measurements of the SW components in the New Entrant How is the trust state communicated? –A signed token from the Trust Environment (TE), of the outcome of the (local) integrity checks is sent in a message from the New Entrant How is the token verified? –The 802.19.1 System validates the token based upon the identity of the TE in the token (and hence the New Entrant) and referring to a Trust Third Party (TTP) verifier –TTP provides security profile/capabilities information about the New Entrant based upon its identity July 2010 Alex Reznik, et. al. (InterDigital)Slide 6

7. doc.: IEEE 802.19-10/0098r0 Submission Integrity based Verification The integrity of the TE in the New Entrant is checked by the hardware anchored Root of Trust (RoT) –RoT and TE itself is trusted via its public key and traceability to a TTP for its security profile/capabilities information TE is loaded and executed Then, the TE prepares a list of the loading order of the modules or groups of components of the New Entrant to verify and load The TE then creates and signs a token to distribute to the 802.19.1 System to attest to its trustworthy state –The token is signed by the private key of the TE –The trust nature of the TE in the device and hence the token may be verified by reference to the TTP The 802.19.1 System then decides on access authorization based upon the integrity verification information The 802.19.1 System and the New Entrant perform mutual authentication The TE in the New Entrant, after authentication, is free to distribute the token to other 802.19.1 System entities to assure them of its trustworthy state July 2010 Alex Reznik, et. al. (InterDigital)Slide 7

8. doc.: IEEE 802.19-10/0098r0 Submission Chain of Trust Illustration July 2010 Proceed with desired operation Stage 1 (TrE) Alex Reznik, et. al. (InterDigital)Slide 8

9. doc.: IEEE 802.19-10/0098r0 Submission Trust-Based Authentication in a Distributed Setting The challenge –No centralized server for authentication –How does the 802.19.1 system “know” who the new entrant is? Address the challenge using the available resources –Assume existence of a trust system –Assume secure authentication/registration with Regulatory TVWS Database How do we leverage these resources? July 2010 Alex Reznik, et. al. (InterDigital)Slide 9

10. doc.: IEEE 802.19-10/0098r0 Submission Trust-Based Authentication in a Distributed Setting Pre-authentication procedue –STEP 1: New Entrant performs internal self-check and produces attestation of platform integrity –STEP 2: New Entrant access TVWS Database. This access is secure –STEP 3: New Entrant uses a secure, trusted process to produce a certificate of successful registration with Regulatory Database using a specific database ID –STEP 4: 802.19.1 authentication procedure Authentication procedure –NEW ENTRANT requests access/participation in a 802.19.1 system –NEW ENTRANT produces a verifiable certificate of its platform integrity –New Entrant identifies itself to the 802.19.1 system using the same ID used to register with regulatory DB and signed with a certificate of success DB registration 802.19.1 system can assess trust in NEW ENTRANT as follows –It verifies NEW ENTRANT’s platform integrity –Platform integrity ensures that New Entrant Regulator DB ID is honestly produced database Id is associated with a PKI key pair to allow signing of the token with the private key of the TE –Platform integrity ensures that the token of successful DB registration is honestly produced –If all of these pass, 802.19.1 can trust that new entrant did indeed successfully register with a (known) regulatory DB and can use that fact as a basis of trust and authentication Note –This process does not require the regulatory DB to provide any services other then those it is required to provide July 2010 Alex Reznik, et. al. (InterDigital)Slide 10

11. doc.: IEEE 802.19-10/0098r0 Submission Chain of Trust For Initial Access July 2010 Initiate Access Request RoT Root of Trust Baseline Platform Integrity OK Reg. DB ID is honest Reg. DB Registration OK Alex Reznik, et. al. (InterDigital)Slide 11

12. doc.: IEEE 802.19-10/0098r0 Submission Policy Commitment: Threat Models Policy modification during transmission –To be addressed by transport security (integrity/confidentiality) –Not discussed further Device tampering –Device commits to policy, but “does not intend” to implement it –Device commits to policy and tries to implement it but can’t because it was tampered with Addressing device tampering threats –requires device security (TE) mechanisms July 2010 Alex Reznik, et. al. (InterDigital)Slide 12

13. doc.: IEEE 802.19-10/0098r0 Submission Policy Commitment: System Example From M. Sherman, “Policy Engine Architecture and Certification,” IEEE SCC41 Document 2010-037 Slide 13 Alex Reznik, et. al. (InterDigital)

14. doc.: IEEE 802.19-10/0098r0 Submission Policy Commitment: How to use TEs We need a 2-step approach Step 1: Prove that the device has not been tampered with –Do it once, as part of access/registration procedure –Generate a token which can be circulated to other 802.19.1 entities Step 2: use a TE-based attestation of honesty with every policy commitment (and de-commitment) –Requires intermittent, but infrequent use of TE functionality –With proof of platform integrity during Step 1 (token generation and passing) this is sufficient to prove that policies that were committed to will be followed July 2010 Alex Reznik, et. al. (InterDigital)Slide 14

15. doc.: IEEE 802.19-10/0098r0 Submission Initial Attachment: Potential Approach 1.New entrant performs a secure start-up by measuring and checking integrity of all system components 2.New entrant sends a report to the 802.19.1 System (generate token) relating to self-check and security profile/capabilities information 3.802.19.1 System analyzes information in the report to assess trustworthiness 4.802.19.1 System responds by allowing access 802.19.1 System may disallow access if the device is deemed untrustworthy based upon the information supplied in the report 5.New entrant performs policy negotiation 6.New entrant broadcasts policy commitments 7.New entrant executes coexistence mechanisms Report Access Control Decision July 2010 Alex Reznik, et. al. (InterDigital) Slide 15

16. doc.: IEEE 802.19-10/0098r0 Submission Policy Changes: Potential Process 1.New entrant sends a report to the 802.19.1 System relating to self-check (token) and security profile information Monitor policy update messages and perform policy re-negotiation AND/OR Broadcast updated policy commitments 2.New entrant executes coexistence mechanisms Report Access Control Decision July 2010 Alex Reznik, et. al. (InterDigital) Slide 16

17. doc.: IEEE 802.19-10/0098r0 Submission Conclusions Discussed how to satisfy security requirement in the SDD Proposed security features to be included July 2010 Alex Reznik, et. al. (InterDigital)Slide 17