On Device-based Identity Management in Enterprises

1. On Device-based Identity Management in Enterprises TrustBus 2007 Marco Casassa Mont Boris Balacheff Hewlett-Packard Labs

2. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

3. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

4. Pervasiveness of Devices • Multiple Types of Devices: • Laptops, • PDAs, • Phones, • Smartphones, … • Used in Multiple Contexts: • Private, Personal Contexts • Work Contexts (Enterprise, etc.) • Device Ownership: • Personal devices, owned by the individuals • Enterprise devices, lent to employees to perform their jobs

5. Device Usage and Related Risks • “Mixed” Usage of Devices: • Same devices (either personal or enterprise owned) are used both at work and for personal matters • REASON: avoid duplication of tools and devices. Keep information in one place. Avoid to bring around multiple devices • Enterprise Devices: • If used for personal matters they might be exposed to further threats and risks the enterprise has to deal with • Device integrity and trustworthiness risks • Personal Devices: • If used at work they might expose unnecessary personal data and private information • Their security standards (patching, upgrades, etc.) could not match Enterprise security requirements: security risks for Enterprise

6. Focus on Enterprise Scenarios • Devices owned by Enterprises • Used for work related matters • Potentially used also for personal matters Applications & Services Access Control • Current Security Solutions • Protection of Enterprise Applications and Services by means of “Middleware” Access Control Systems mainly based on “Human-Identities” • Issues • “Device-Identities” are generally not managed, if not by strongly coupling them to “Human-Identity” • Trust and Assurance is required about authenticity, validity and integrity of devices • Dealing with Device Identities and their association to humans is not trivial • Losing important contextual information about the device identity (and its properties) that could be used during access control processes Information & Data ENTERPRISE

7. Current Identity Management in Enterprises[1/2]

8. Self- Registration: Personal Data (Human Identity) Audit Logs & Compliance Checking Settings Data Events Data Queries Enterprise Systems Data Repositories Current Identity Management in Enterprises [2/2] Access Request To Apps Applications/ Services Web Portal Third Parties Users Employees User Provisioning & Account Management Admins Id Federation Management Access Control System Identity Management Middleware ENTERPRISE

9. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

10. Problem Space • How to Manage Device Identity in Enterprises? • How to Balance “Human Identities” • with “Device Identities”? • How to deal with Identity Management and Access Control • at the Enterprise Application/Service Level? • Need to leverage Enterprise Identity Management Solutions also to • deal with Device Identities • Do not focus only at the “Network Level” (approach followed by most of related work) +

11. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

12. Requirements • Need toModel and Explicitly Represent a Device Identity • “Assess” and “Certify” a Device Identity(dealing with trust issues) • Securely Store and Protect a Device Identity • Be able to Associate Users’ Identities to Devices’ Identities • Be able to Provision Devices’ Identities(along with users’ identities) • within enterprise systems and IT security systems, such as access control systems • Deal with the Lifecycle Management(inclusive of modification and disposal) • of Devices’ Identities, in addition to the Lifecycle Management of • traditional Users’ Identities • Define and Manage Fine-grained Access Control Policies that can • keep into account any combination of Users’ Identities, Devices’ Identities, • Device Properties and other Contextual Information

13. Our Analysis • Analysis based on the Enterprise Context, taking into account • Requirements and current Enterprise Identity Management • Solutions. Three key Aspects have been Investigated: • Enterprise Processes for Device-based Identity • Management • B. Modelling, Representation and Storage of Device • Identity • C. Fine-grained Access-Control Policies involving • Device Identity and User Identity

14. Enterprise Processes for Device-based Identity Management Access Control Settings and Policy Definition • Identity and • Policy • Lifecycle Mgmt: • Updates • Disposal Identity Creation and Certification Identity Provisioning in Enterprise Systems and Solutions The management of Device Identities in Enterprises has to comply with current Enterprises Identity Management processes, specifically the ones used to deal with User/Human Identities. These processes operate at the enterprise “middleware” level.

15. B. Modeling, Representation and Storage of Device Identity [1/3] • Device Identity consists of Set of Information that “Uniquely” • Identify the Device: • Device unique identifier • Logical name • Manufacturing properties of the device • “Expected” location (in case of static device) • Intended usage and business purpose • Potential list of device’s owners/legitimate users • … • NOTE: there is currently no agreement in the industry of what exactly • a “Device Identity” is … ?

16. B. Modeling, Representation and Storage of Device Identity [2/3] • Requirements include: • Representation of Device Identity • Safe Storage of this Identity • Usage of this Identityfor Authentication, Authorization, etc. • Main Options to Represent Device Identities: • “Uncertified” Device Identity • Just a collection of identity attributes • No assessment of certification by third part  Open to tampering • “Certified” Device Identity • Certified collection of attributes • Potential usage of digital certificates, XML-signed files, PKI, etc. • Further trust if certification is made by a “trusted” party (e.g. the Enterprise). ? • Storage of Digital Identities: • Required both for Certified and Uncertified Device Identities • In case of “Certified Device Identities” need also to store a Secret • (e.g. cryptographic private key) ?

17. B. Modeling, Representation and Storage of Device Identity [3/3] • Role of Trusted Platform Modules (TPM): • TPM specified by Trusted Computing Group (TCG) • TPM provides tamper-resistant cryptographic module • Currently available in most laptops and PCs • Can be used to generate a Cryptographic Key in a secure way • Provides assurance that the key can only be used on the device • it was provisioned, to represent the device identity • TPM ships with a built-in Endorsement Credential installed by • the manufacturer • This Endorsement Credential can be used to support a device • identity provisioning solution to remotely check the device has • appropriated trusted computing capabilities to protect the device • identity wit hardware and bind it to device (via TPM)

18. C. Fine Grained Access-Control Involving Device Identities and User Identities [1/4] • Device Identities, along with User/Human Identities can be used to • define Enterprise Access Control Policies (by enterprise administrators) • Access Control Policies are used for Authentication and Authorisation • aspects to protect Enterprise Resources (applications, services, etc.) • Traditional User-based Access Control Policies are conceptually represented • by means of a “Resources x Users” Matrix: • Users: • Known Users • Unknown/Anonymous • Users Protected Resources Access Rights: - Allow/Deny rights - Complex Constraints (e.g. time based, …)

19. C. Fine Grained Access-Control Involving Device Identities and User Identities [2/4] • This “Resources x Users” Matrix is potentially a good starting point to • explore how to factor-in Device Identities … • Two related Models have been investigated in our analysis: 1. Representations of Devices as a “Special Type” of User: • Known/Unknown Devices for Known/Unknown Users • Hierarchies of Devices and Resources • Access control keeping into account either’s user identities or device identities • Fine-grained access constraints/rules can be expressed in the intersection of user/device and resource • Rules can define join authentication (AND) of both a user and a device: - check users and/or device properties - check for TPM presence on device …

20. - Unknown Users - Known Users User1 User 2 User 3 … C. Fine Grained Access-Control Involving Device Identities and User Identities [3/4] 2. Representations of Devices asResources: • Devices are listed (either separately or within hierarchies) as Resources • A Device can be described by its own Identity • Cons: • How to deal with Unknown Devices? It would be an unknown resource … • How to Manage the Association of Access Control Policies? • In this model devices are just resources – there is still the need to enable • access to other resources purely based on their device identities -- Protected Resources -- Devices

21. C. Fine Grained Access-Control Involving Device Identities and User Identities [4/4] Limitation of these Models: • In both Models Users and Devices are represented in the same “Matrix”: • Access constraints applies to user identity AND device identity (unless one of them is unknown) • No easy way to represent with the same model a constraint either on “user identity AND device identity” or “user identity OR device identity” Alternative Models under Investigation: • Usage of multiple Access Control Matrices: “Resources x Users” and “Resources x Devices” • Usage of “three-dimensional” matrices • Usage of “Tree of Matrices” … •  All these models have Limitations in terms of Complexity in defining them and Managing Associated Information • Most realistic and feasible approach (at the current stage) is Model 1 i.e. Devices as “Special Types” of Users

22. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

23. Our Approach to Device-based Identity Management [1/3] • Pragmatic Approach: • Leverage state-of-the-art Enterprise Identity Management • solutions to deal with Identity Provisioning and Access Control • of User Identities and Extend them to manage Device Identities • Recommended Usage of Trusted Computing components • (TPMs) to: • Protect Device Identity • Address need for Certification and Trust Assurance of this Identity • Work in Progress …

24. Our Approach to Device-based Identity Management [2/3] • Current Proposed Solution based on: a. Explicit Certification and Protection of Devices’ Identities by means of: - Trusted Platform Module (TPM) - Enterprise “Identity Certification Service” (…) • Association of Human Identities and Devices’ Identities • Explicit Provisioning and Management of the lifecycle of Devices’ Identities in Enterprise Identity Management Systems • Support Fine-grained, Policy-driven Access Control Policies on Enterprise Resources based on Model 1 (Devices as Special Types of Users) and Contextual Information e. Enterprise Device Identities configured by Enterprise Administrators

25. Our Approach to Device-based Identity Management [3/3] • Device-based Identity Properties: • Managed Devices might or might not have TPM modules • In both cases, a key-pair is associated to a device • A device identity is in the form of a signed certificate AND certified • by an “Identity Certification Service” • Identity Certification Service: • It is a “Certification Authority” run by the Enterprise (or TTP) • Can check (and keep track), when issuing identity certificates, if: • Device is TPM enabled (key generation and stronger protection) • Device is not TPM enabled • Self-Registration Web Service: • Authenticate Enterprise Administrators (or potentially device owners …) • Collect Identity Attributes • Start the process of generating device identity (via Identity Cert. Service) • Start the Provisioning Process and Access Control configuration …

26. Policy & Config. Database Inside TPM Device-Identity Management Model CA1(TPM) CA2(No TPM) Identity Certification Service Enterprise User Provisioning Solution 3. Provisioning 2. Certificate signature 4. Update Certificate Info Self-Registration Web page 10. Response 200 / 403 Enterprise Access Control Solution 8 Policy Check 1. Key creation 7. Certificate verification PDP 5. Resource request PEP 9. Allow / Deny TMP Mgmt. Solution 6. Certificate Authentication Web Server + Web Apps Administrator: Set Access Control Policies User Device

27. Policy & Config. Database Inside TPM MS CSP Current Status: Full Working Prototype CA1(TPM) CA2(No TPM) Identity Certification Service Enterprise User Provisioning Solution HP OpenView Select Identity 3. Provisioning 2. Certificate signature 4. Update Certificate Info Self-Registration Web page HP OpenView ProtectTools 10. Response 200 / 403 Enterprise Access Control Solution 8 Policy Check 1. Key creation 7. Certificate verification PDP 5. Resource request PEP 9. Allow / Deny TMP Mgmt. Solution HP OpenView Select Access 6. Certificate Authentication Web Server + Web Apps Administrator: Set Access Control Policies User Device

28. Demonstrator

29. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

30. Related Work & Open Issues • The concept of Device Identity is not new: see MAC address, IP address, etc. • Multiple initiatives to Standardise Device Identities (not clear how they evolve) • Solutions already available to securely protect data in devices: TPM, • Hardware Security Modules (HSMs) •  However most solutions focus on locally protecting • device identities, NOT really how to provision them and deal with • access control for Applications and Services at the enterprise “middleware” • Relevant work done in the context of Liberty Alliance Project, • with the Identity Capable Platforms (ICP) & Provisioning Services •  We are involved in this initiative • Other work on Device Identities and their management is at the Network • Level (bottom-up approach). NOT really linked to Enterprise IdM • middleware • Open Issue: gap between top-down approach (ours) and existing • bottom-up approaches (e.g. network-based)

31. Next Steps • Further refine out approach and technology along with expressiveness • of related access control policies • Further explore alternative model to represent device-identities in • access control policies • R&D about the full-lifecycle management of Device Identities • Explore how to reconcile network-based with application-based management • of Device Identities

32. Presentation Outline • Background on Device Identities • Problem Space: Device-Identity Management • Requirements and Our Analysis • Our Current Approach • Related Work, Current Issues and Next Steps • Conclusions

33. Conclusions • Growing importance and usage of (personal) devices • in enterprises • Problem space: how to manage device-identities • in enterprises? • Need to leverage and extend existing IdM solutions … • Explored various models of Device Identities: • gone for a Model where Devices are a special type of • Users • Presented a solution for issuing device-identities, • provisioning them and setting access control constraints. • It is feasible. Developed prototype and demonstrator • Work in Progress … A few Issues to be Addressed