Access Control in KMIPv1.1/v2

April 19, 2023

© 2009 IBM Corporation

Access Control in KMIPv1.1/v2

Robert Haas <[email protected]>

April 19, 20232 © 2009 IBM Corporation

IBM Research - Zurich

Access Control in KMIPv1

• Operation Policy Name placeholder – Object Attribute– Not mandatory– Defines the default permissions



Access Control in KMIPv1.1/v2: Proposal

• We suggest two complementary mechanisms– Basic Access Control– Strict Access Control (SAC)

• Basic Access Control– Possibly mandatory (at least regulated through profiles)– Access Control Lists (ACLs) attached to objects

• Object Attribute • Consists of (user/role,permission) pairs

– User Permission Lists (UPLs)• For operations that refer to not yet existing objects (Create, Create Key Pair, Register)• “global” list of (user/role, permission pairs)

– “global” is here in the sense of “unique per key-management domain”– Finer granularity (e.g., multiple subdomains) possible

• Strict Access Control (SAC)– Possibly optional (also could be regulated through profiles)– To prevent KMIP API attacks introduced by object dependencies

• Object dependencies are introduced notably through derivation and key wrapping• API might “leak” information about dependent keys• This may lead to ACL violation if object interdependencies are not checked

– Through standardization of additional SAC specific attributes (in addition to Basic AC)



Basic Access Control (BAC)

• ACLs and UPLs are forseen as lists (user/role, permission) pairs– ACL is foreseen as a potentially mandatory attribute of an object– A UPL (potentially also mandatory) is not attached to any object

• Users– There is a tight interplay between the standardization of user representation in KMIP

(cf. Client Registration Action Item)– Special users any and creator already in KMIPv1

• Permissions– Suggested in the following– Rough initial proposal, to be refined for each Object type



BAC: Proposed UPL permissions

Create, Create Key Pair, Register : create

Operations and permissions



BAC: Proposed ACL Permissions

• Special permission admin permitting all operations• Rekey:

– rekey for the targeted Managed Object (MO)– irrespective of create in UPL

• Derive: – derive for MO– irrespective of create in UPL

• Certify, Re-certify: – certify for MO– irrespective of create in UPL

• Locate, Check, Get Attrs, GetAttrList: – read_attributes for MO

• Get:– for MO: read (for Get in cleartext), export (for Get

wrapped)– for the wrapping key: wrap (Get wrapped)

• Add, Modify, Delete Attr, Activate, Revoke: – modify_attributes for MO (to change everything

but ACL)

Operations, ACL permissions and UPL permissions

• Obtain Lease, Get Usage Allocation:

– read or export for MO

• Destroy:

– destroy for MO (or simply admin)

• Archive/Recover:

– archive for MO (or simply admin)

• Validate:

– read for all given Certificate objects

– TBD: should read be implicit for all Certificates?

• Query:

– no permission

• Cancel, Poll:

– TBD: separate permission for asynchronous operations (if at all)



Strict Access Control (SAC): Motivation

• API attacks on key management APIs – a legitimate concern

• Operation on cryptographic keys might introduce dependencies between keys– Example operations: Derive, Get (wrapped)– If only basic ACL/RBAC mechanisms are implemented/specified in KMIPv2, these

might be circumvented by exploiting the KMIP API

• Such API attacks are applicable to existing practical key management interfaces like PKCS #11



Example of the Attack on BAC

(Note: already presented at KMIP f2f Sep 28-29 2009)

• Use case– Tape drive encryption

• Setup – Key B is used to encrypt the tape drive – Key B wrapped with key A is stored on a tape drive (e.g., by user Bob) – Initially no user (except administrator) has a permissions to read the key material of

Key A– Administrator gives the permission to user Alice to read the key material on key A, not

knowing that it was used to wrap key B– Administrator does not intend to allow Alice the permission to read key B

• Attack– Alice reads the key material of Key A from KMIP server, gets the wrapped Key B,

unwraps it and obtains the key material of Key B



Example (Get Wrapped)

KMS

Key A

Key B

2. Get

1. Get W rapped

Key A

Key B

Key A

Key B

3. Local Unw rapping

User/Key Key A Key B

Alice read -

Bob wrap export

Bob

Alice



SAC: Details

• Proposed solution for the API attack problem in future KMIP servers– Support could be optional (perhaps related to certain KMIPv1.1/v2 profiles)

• Standardize KMIP attributes to track dependencies among keys and modify basic AC mechanisms to account for these

• References: 1. Christian Cachin and Nishanth Chandran. A secure cryptographic token interface. In Proc. Computer Security Foundations Symposium (CSF-22). IEEE, July 2009.

2. Mathias Bjorkqvist, Christian Cachin, Robert Haas, Xiao-Yu Hu, Anil Kurmus, Rene Pawlitzek, and Marko Vukolic, Design and Implementation of a Key Lifecycle Management System. To appear in Proc. Financial Cryptography and Data Security (FC’10), January 2010. Also available as IBM Research Report RZ 3739, June 2009.



SAC: Proposed Attributes

• Strict (flag, boolean)– Denotes whether strict policy applies to an object– Important for support of legacy applications in use cases where SAC guarantees are

not required/possible to implement

• Dependents– Set of UUIDs of Dependent objects

• Ancestors– Set of UUIDs of Objects that have a given object in the Dependents

• Readers– Set of users that have read the cleartext of the key



Comments?

Access Control in KMIPv1.1/v2

Documents

Transcript of Access Control in KMIPv1.1/v2