1 / 17

802.19.1 Security Procedures

802.19.1 Security Procedures. Authors:. Date: 2010-07-12.

ccassidy
Download Presentation

802.19.1 Security Procedures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.19.1 Security Procedures Authors: Date: 2010-07-12 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. Alex Reznik, et. al. (InterDigital)

  2. 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 Alex Reznik, et. al. (InterDigital)

  3. 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 Alex Reznik, et. al. (InterDigital)

  4. 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 Alex Reznik, et. al. (InterDigital)

  5. 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) Alex Reznik, et. al. (InterDigital)

  6. 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 Slide 6 Alex Reznik, et. al. (InterDigital)

  7. 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 Slide 7 Alex Reznik, et. al. (InterDigital)

  8. Chain of Trust Illustration Proceed with desired operation Stage 1 (TrE) Slide 8 Alex Reznik, et. al. (InterDigital)

  9. July 2010 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? Alex Reznik, et. al. (InterDigital)

  10. July 2010 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 Alex Reznik, et. al. (InterDigital)

  11. Chain of Trust For Initial Access Initiate Access Request Reg. DB Registration OK Reg. DB ID is honest Baseline Platform Integrity OK RoT Root of Trust Slide 11 Alex Reznik, et. al. (InterDigital)

  12. 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 Alex Reznik, et. al. (InterDigital)

  13. Policy Commitment: System Example • From M. Sherman, “Policy Engine Architecture and Certification,” IEEE SCC41 Document 2010-037 Alex Reznik, et. al. (InterDigital)

  14. 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 Alex Reznik, et. al. (InterDigital)

  15. July 2010 Initial Attachment: Potential Approach • New entrant performs a secure start-up by measuring and checking integrity of all system components • New entrant sends a report to the 802.19.1 System (generate token) relating to self-check and security profile/capabilities information • 802.19.1 System analyzes information in the report to assess trustworthiness • 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 • New entrant performs policy negotiation • New entrant broadcasts policy commitments • New entrant executes coexistence mechanisms Report Access Control Decision Alex Reznik, et. al. (InterDigital)

  16. July 2010 Policy Changes: Potential Process • 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 • New entrant executes coexistence mechanisms Report Access Control Decision Alex Reznik, et. al. (InterDigital)

  17. Conclusions • Discussed how to satisfy security requirement in the SDD • Proposed security features to be included Alex Reznik, et. al. (InterDigital)

More Related