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

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

doc.: IEEE /0098r0 Submission 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

doc.: IEEE /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

doc.: IEEE /0098r0 Submission Authentication Procedures Centralized architectures –Can use standard approaches (e.g X) –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

doc.: IEEE /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 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

doc.: IEEE /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 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 System then decides on access authorization based upon the integrity verification information The System and the New Entrant perform mutual authentication The TE in the New Entrant, after authentication, is free to distribute the token to other System entities to assure them of its trustworthy state July 2010 Alex Reznik, et. al. (InterDigital)Slide 7

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

doc.: IEEE /0098r0 Submission Trust-Based Authentication in a Distributed Setting The challenge –No centralized server for authentication –How does the 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

doc.: IEEE /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: authentication procedure Authentication procedure –NEW ENTRANT requests access/participation in a system –NEW ENTRANT produces a verifiable certificate of its platform integrity –New Entrant identifies itself to the system using the same ID used to register with regulatory DB and signed with a certificate of success DB registration 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, 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

doc.: IEEE /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

doc.: IEEE /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

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

doc.: IEEE /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 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

doc.: IEEE /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 System (generate token) relating to self-check and security profile/capabilities information System analyzes information in the report to assess trustworthiness System responds by allowing access 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

doc.: IEEE /0098r0 Submission Policy Changes: Potential Process 1.New entrant sends a report to the 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

doc.: IEEE /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