Cryptography is a discipline of mathematics and computer science concerned with information security and related issues, particularly encryption/decryption of information and authentication of identity. In so called “data-in-movement” applications, cryptography has been applied extensively for securing information flows amongst communicating participants, e.g., client nodes, over communication channels. Cryptography has also been applied for securing information in data storage mediums and databases in what is known as “data-at-rest” applications.
Symmetric cryptography and asymmetric cryptography are known classes of algorithms that use keys having one or more secret parameters for encryption and decryption of information and authentication. In symmetric cryptography, keys represent shared secrets which are known a priori amongst communicating participants. Systems secured with symmetric-key algorithms use relatively simple encryption and decryption computations. Such systems also require choosing, distributing and maintaining the shared secret key amongst the communicating participants. In order to avoid security breach and potential discovery by a cryptographic adversary, the shared secret key must be changed often and kept secure during distribution and in service, making symmetric-key cryptography impractical and hard to scale for securing large systems.
Asymmetric cryptography uses a pair of mathematically related keys known as public and private keys, which obviate the need for prior knowledge of a shared secret key amongst communicating participants. While computationally more intensive, asymmetric key cryptography overcomes scalability disadvantages associated with symmetric key cryptography. Public key infrastructure (PKI) is a known system for securing information using asymmetric key cryptography. In such system, a party at one computer station digitally signs messages using a randomly created private key and a party at another computer station verifies the signature using a distributed public key derived from the private key. The public keys of the communicating participants are distributed in corresponding Identity Certificates, also known as Public Key Certificates, issued by one or more trusted parties called Certificate Authorities (CAs). In this way, PKI keeps messages secret from those that do not possess the private key and the Identity Certificates allows anyone having the associated public key and identity certificate to verify that the message was created with the private key. Consequently, PKI enables communicating parties to be authenticated to each other and to use the public key information in Identity Certificates to encrypt and decrypt messages, thereby establishing message confidentiality, integrity and authentication without advance exchange of shared secret keys.
Each Identity Certificate includes a digital signature that binds a public key with an identity represented by such information as name, e-mail address, etc. By digitally signing the Certificate, a CA attests that the public key belongs to the identity, i.e., the person, organization, server, or other entity noted in the Certificate. The CA is often a trusted third party that issues digital Certificates for use by communicating parties. The requirement of trust obligates the CA to somehow verify the identity credentials of communicating parties. It is assumed that if the parties trust the CA and can verify its signature, they can also verify that a public key does indeed belong to whomever is identified in the Certificate.
Some enterprise-scale PKI systems rely on Certificate chains to establish a party's identity. Under such scheme, a Certificate may be issued by a CA whose legitimacy is established for such purpose by a higher-level CA, and so on. This produces a Certificate hierarchy composed of several CAs, often more than one organization. CAs can manage issuance of Certificates using various computers and assorted interoperating software packages from several sources. This makes standards critical to PKI operation. IETF PKIX working group is involved with standardization of public key Certificate format, including a certificate standard known as X.509.
Various point-to-point secure communication protocols that use cryptography are known. Examples of such protocols include Secure Sockets Layer (SSL), Transport Layer Security (TLS), Secure Shell (SSH), IP Security (IPsec), and High Assurance Internet Protocol Interoperability Specification (HAIPIS). SSL and TLS provide cryptographic endpoint authentication for applications that communicate within client-server based networks for preventing eavesdropping, tampering, and message forgery during communications. SSH is a set of standards and associated network protocols that allow for establishing a secure channel between a local and a remote computer. This protocol uses public-key cryptography to authenticate the remote computer. IPsec is a standard for securing Internet Protocol (IP) communications by encrypting all IP packets for authentication, data confidentiality and message integrity. A HAIPE (High Assurance Internet Protocol Encryptor) is a Type 1 encryption device that complies with the National Security Agency's HAIPEIS. The cryptography used is Suite A and Suite B, also specified by the NSA as part of the Cryptographic Modernization Program. HAIPEIS is based on IPsec with additional restrictions and enhancements. A HAIPE is typically a secure gateway that allows two enclaves to exchange data over an untrusted or lower-classification network. In conventional secure systems, such as those that use the foregoing protocols, encrypted messages are communicated over channels within the network, often through a firewall, based on authentication of identities of the communicating parties by CAs. As long as the identity of the communicating parties are authenticated, conventional secure systems allow the parties to communicate with each other over channels.
Applications often provide access to resources based on credentials supplied by the user. Typically, such applications verify the role of a user and provide access to resources based on that role. Roles are often used in financial or business applications to enforce policy. For example, an application might impose limits on the size of the transaction being processed depending on whether the user making the request is a member of a specified role. Clerks might have authorization to process transactions that are less than a specified threshold, supervisors might have a higher limit, and vice-presidents might have a still higher limit (or no limit at all). Role-based security can also be used when an application requires multiple approvals to complete an action. Such a case might be a purchasing system in which any employee can generate a purchase request, but only a purchasing agent can convert that request into a purchase order that can be sent to a supplier.
One known role based identity management system is provided by Microsoft's .NET Framework. Under .Net Framework, a “principal” represents the identity and role of a user and acts on the user's behalf. .NET Framework applications can make authorization decisions based on the principal's identity or role membership, or both. A role is a named set of principals that have the same privileges with respect to security (such as a bank teller or manager). A principal can be a member of one or more roles. Therefore, applications can use role membership to determine whether a principal is authorized to perform a requested action.
Another role based system is an analytical collaboration platform called Eurekify Sage Enterprise Role Manager (ERM)®, which allows organizations to create and manage role-based privileges models deployed in target platforms. Sage ERM enables organizations to exploit the benefits of Role-Based Access Control (RBAC) to manage their privileges and policies from a business perspective, and to achieve their identification management and compliance goals.
Currently, Object Management Group, OMG, has drafted a request for proposal (OMG Document: bmi/2008-02-07) for a Role Based Access Policy (RBAP) Metamodel to define role based access control (RBAC) policies and personnel authorizations that are applied by a RBAC runtime environment. The Metamodel is intended to be a platform independent model (PIM) that supports the exchange of an RBAP model between modeling tools and runtime systems.
In another conventional approach, Lawrence Berkeley National Laboratory also known as Berkeley Lab has developed a system called Akenti. Akenti addresses the issues raised in allowing restricted access to resources in distributed networks which are controlled by multiple stakeholders. Akenti provides a way to express and enforce an access control policy without requiring a central enforcer and administrative authority. Akenti's architecture is intended to provide scalable security services in distributed network environments. Akenti is designed to allow each stakeholder of a resource to enforce its access control requirements independent of other stakeholders. Akenti allows each stakeholder to change its requirements at any time and to be confident that the new requirements would take effect immediately, and to provide high assurance of integrity and non-repudiability in the expression of the access control requirements.
Akenti makes use of digitally signed Certificates. A Certificate may assert an identity (Identity Certificate), attest to an attribute of a subject (Attribute Certificate), or state a condition to be met (Use-condition Certificate). The Certificates in Akenti are capable of carrying user identity authentication as well as resource usage requirement and user attribute authorizations. A “use-condition” in Akenti relates to a stakeholder's requirement that a potential user must fulfill by producing a corresponding attribute Certificate before being allowed to use a resource. The attribute relates to a characteristic of a person or other identifiable entity. Stakeholders in Akenti can impose a use-condition that a user must belong to a particular group in order to access the resource controlled by such stakeholder. Therefore, a user wanting access to such resource must demonstrate membership in the particular group via a corresponding Attribute Certificate. Attribute Certificate asserts that a user or resource possesses a named attribute for a particular use condition.
In Akenti's system, however, the stakeholders are associated with resources. Such stakeholders control resource access based on use conditions that require the users to meet specified attributes. Under Akenti, resource access is permitted as long as the users meet the attribute requirements specified by the resource stakeholders. One of the drawbacks of Akenti's system is that it does not accommodate the security requirements of stakeholders or authorities that are not resource stakeholders. Such non-resource stakeholders do not have control over users' access privileges to the resources if the resource stakeholders do not prevent the users from accessing the resources. In other words, the resource stakeholders in Akenti may allow resource access to users that may be prohibited from such access by non-resource stakeholders.
Also knows is a computer network authentication protocol called Kerberos, which allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. A suite of free software published by Massachusetts Institute of Technology (MIT) implements the Kerberos protocol primarily for a client-server model to provide mutual authentication such that both the client and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.
Kerberos builds on symmetric key cryptography and requires a trusted third party, termed a key distribution center (KDC), which consists of two logically separate parts: an Authentication Server (AS) and a Ticket Granting Server (TGS). Kerberos works on the basis of “tickets” which serve to prove the identity of users.
The KDC maintains a database of secret keys, each entity on the network, whether a client or a server, shares a secret key known only to itself and to the KDC. Knowledge of this key serves to prove an entity's identity. For communication between two entities, the KDC generates a session key which they can use to secure their interactions. Using the Kerberos protocol, however, the “tickets” must be verified by contacting the KDS, or a central server, thereby introducing a single point of failure for the implemented system. The single point of failure property of the Kerberos systems is not beneficial for systems that have intermittent or failure-prone communications capabilities such as embedded or autonomous systems.
Therefore, as the security needs in information systems become more complicated, there exists a need for a secure system and method that manage access based on advanced and sophisticated security parameters.