Nesca f e has installed coffee vending machines across all major cities. .... Thus, in KNesca f e's name space Vending Machine is a group definition, whose ...
ROADS: Role-based Authorization and Delegation System Authentication, Authorization and Applications RK Shyamasundar
Vishwas Patil
Abstract In this paper, we shall describe the design and implementation of our Role-based Authorization and Delegation System (ROADS), based on the SPKI/SDSI framework. We have devised a flexible access control mechanism called flexi-ACL that allows us to integrate different kinds of authentication schemes in our setup. Using such flexible access control schemes, we show how different PKIs and other authentication schemes (sometimes proprietary) can be integrated without foregoing security. ROADS also support classical features of SPKI/SDSI, such as group memberships, threshold certificates etc. The application of our system is illustrated with an experimental integration with our distributed auction system (SeTiA1 ); to achieve the closure time for auctions by arriving to a consensus among participating auction servers distributed across independently administered domains.
1 Introduction The spurt of ubiquitous computing over the Internet in recent past has attracted many to exploit the communication between the communicating peers. Naturally, security of such transactions play a vital role and calls for cryptographic based methods. One of the primary requirements for achieving cryptographic security has been the development of underlying public-key infrastructure (PKI). X.509 [1, 2] has been one of such widely deployed PKI. The perceived complexity and inherited hierarchy of X.509 inhibits itself from scaling and addressing complex trust models. More and more applications are getting web-enabled, web-enabling applications means users can access them through the Internet, making these application more prone to unauthorized accesses. Such applications require a mechanism to distinguish between authorised and un-authorised users for restricting the resource access to only authorised users. Moreover, modern day applications over the Internet demand properties like; role-based access (to achieve interoperability between entities and the authorizations associated against them) and flexible policy specification (for effective expression and manageability of security policies) to efficiently grant access over the resource. SPKI/SDSI [3, 4] is a promising architecture for such applications. It is a novel distributed PKI which emphasises uniform treatment of principals and provides clean methods for naming, defining groups, delegating authorizations etc. The concept of local name spaces associated with each key helps in the uniform treatment of principals in general and induces a powerful expressiveness that leads to achieve the properties of the traditional transactions and also aids in achieving various facets of privacy. In this paper, we shall describe the design and implementation of ROADS. We have devised a flexible access control mechanism, called flexi-ACL [5], that allows us to integrate different kinds of authentication schemes into our setup for dynamic policy specification. Using such flexible access control schemes, we also show how different PKIs and authentication schemes can be integrated without foregoing security. ROADS framework also supports the classical features such as group memberships, threshold certificates etc. that are supported by underlying SPKI/SDSI framework. Some of the characteristic features of our system are; 1. Independent authentication and authorization mechanisms, 2. Flexible ACL specifications making use of group and threshold definitions, 3. Efficient interfaces to e-commerce systems through: (a) tokenization of certificates, and 1 secure
multi-auction system developed at TIFR
1
(b) maintenance of certificates through web-forms. The application of our system is illustrated with an experimental integration with SeTiA: a distributed auction system developed here [6], to derive the closure time for distributed auctions in a secure and consensual fashion. Further, we shall illustrate the privacy and anonymity aspects achieved for e-transactions through ROADS. Rest of the paper is organized as follows: In Section 2, we provide an overview of the SPKI/SDSI framework highlighting its structure and representation of its certificates with examples. In Section 3, we have discussed the access control specifications under flexi-ACL with examples, followed by the implementation aspects of ROADS. In Section 4, we present a typical application of our system along with various privacy layers that our system provides. We conclude with future directions in Section 5.
2 An overview of SPKI/SDSI The SDSI and SPKI efforts (initiated separately) were both motivated in part by the perception that the existing proposals for a public-key infrastructure (such as X.509-based schemes that require global certificate hierarchies) are both excessively complex, rigid and incomplete. Their complexity arises from a dependence on global name spaces and an attempt to formalise too many things. Their incompleteness can be immediately perceived if one tries to define a security policy (e.g. write an ACL) based on the scheme. SPKI/SDSI can be considered as a system evolved from PGP and X.509 with certain distinct new features like local name spaces, separate certificates for name and authorization definition. One of the drawbacks of the previous schemes of certificate verification (read as X.509) has been the need of maintaining the Certificate Revocation Lists (CRL). SPKI/SDSI overcomes the need of CRL by exercising on-line re-confirmations. Also, it does not need complex interfaces such as ASN.1 [7]. Furthermore, while authenticating in the traditional schemes it is difficult to achieve privacy, since the much of the information belonging to the identity (embedded into the X.509 certificate along with all the authorizations the principal can perform) is not necessarily required for the task on hand, unnecessarily revealing personal information. The most striking features of this framework is its decentralized name space, unlike X.509. In SDSI, the owner of each public key has a name space which is local to the key. Such name spaces can be interlinked together in a flexible and powerful manner to enable chains of authorization and define groups of authorised principals. In the following, we provide an overview of various features of SDSI/SPKI to provide an understanding of its usage and implementation. Primitives: The basic set of primitives are defined below: • • • • • • •
Principal [K]: The person or entity represented by the key. Issuer: The Principal signing the certificate. Identifier [A]: The identifier determines the local name that is being defined by principal. Subject [S]: The principal to whom the issuer refers with identifier A. Delegation bit [D]: Boolean value; if true, further delegation of authority is allowed. Validity period [V]: The range of dates for which the certificate is valid. Tags [T]: A tag is a set of requests. The final arbiter of what needs to be a and what parameters a particular needs is the designer of the code that verifies a certificate.
Naming [4] the variables or objects is one of the most important aspects in computation. The power of SPKI/SDSI scheme lies in naming the various objects and components. Before going into technical details of the system, let’s take a look at the sample scenario which will be used in the sequel. Sample Scenario: Nescafe Example Nesca f e has installed coffee vending machines across all major cities. It has authorised two distributors D1 and D2, who will issue pre-paid smart cards to the customers for accessing the vending machines on-behalf of Nesca f e. The distributors have further delegated their right for authorising customers to several retailers R1, R2, ... , R6. These retailers will be issuing the pre-paid smart-cards to the customers. Using this setup, we will demonstrate authentication, authorization, delegation of powers etc. Figure 1, gives a notion of flow of authorization from Nesca f e owner to the end customers.
2
KNesca f e
Nescafe
KD1
KD2
D1
D2 V M1
V M2
V M3
V M4
V M5
ACL
ACL
ACL
ACL
ACL
KV M1
KV M2
KV M3
KV M4
KV M5
KR2
KR1
R1
KR4
KR3
R2
R3
KR5
R4
C1
C2
C5
C6
KC1
KC2
KC5
KC6
KR6
R5
R6
VM = SPKI−enabled Vending Machine D = Distributors
R = Retailors
C = Customers
Figure 1: SPKI-enabled Vending Machines and its Authorised Retailers, Customers In the preceding subsections, we describe notations employed to represent the certificates in SPKI/SDSI. Most of the times the primitives are shown inside a box, this is done for the reader’s better understanding of the subject. Public Key: The publicly-displayable component of a pair of cryptographic keys used for asymmetric cryptography. Counterpart of this key is assumed to be stored in Personal Security Environment. Hereafter, we will denote the keys by an alphabet K and its owner’s name as a subscript to K. So, KNesca f e is a key of principal Nesca f e.
2.1 Certificates Definition: A document that attests to the truth of something or the ownership of something can be called a certificate. Any SPKI/SDSI certificate will have at least two distinct parts in it, issuer and subject. A subject can be only a key or a local name or an extended name. There are two kinds of certificates: name certificates and authorization certificates. The S-expression based representations of these certificates are shown in Figures 2, 3, 4, 6, and 8. The S-expression [8] format of certificates will be too cumbersome while explaining the certificate chain generation process etc. Instead, we will use meta-symbols replacing the original primitives for the sake of brevity. So, the certificate in Figure 2, can be represented by equation 1, sub ject
issuer
z }| { z }| { KNesca f e Vending Machine −→ KV M1 | {z }
(1)
local name
This notation binds the subject (KV M1 ) to the issuer (KNesca f e ) using an identifier (Vending Machine). Similarly, KNesca f e has issued name certificates to all other vending-machines KV M2 , KV M3 , KV M4 , KV M5 . Therefore, KNesca f e Vending Machine −→ KV M2 KNesca f e Vending Machine −→ KV M3
(2) (3)
KNesca f e Vending Machine −→ KV M5
(5)
KNesca f e Vending Machine −→ KV M4
3
(4)
(certificate (issuer (name (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) Vending_Machine )) (subject (public-key rsa-with-md5 (e |Egr3iLrJIQ4ert4DFG5g|) (n |Asr66RgdeGRT34ghP9errFZ02gAIYZ5rEQpEQq8ZyM21asdrTfW6wQfsFRT=|))
)
(not-before "2002-01-01_09:00:00") (not-after "2003-01-01_09:00:00")) Figure 2: Name Certificate issued by Nesca f e (certificate (issuer (name (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) Customers (subject (ref
))
(public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) Distributors
Retailers
Customers
))
(not-before "2002-01-01_09:00:00") (not-after "2003-01-01_09:00:00")) Figure 3: Name Certificate issued by Nesca f e (subject is an extended name) Observing the above certificates, one can notice that KNesca f e has used a common identifier Vending Machine in all the certificates. This is generally called as grouping. Let’s represent above certificates by following equation KNesca f e Vending Machine −→ {KV M1 , KV M2 , KV M3 , KV M4 , KV M5 }
(6)
The group members are listed on the right hand side of the equation (inside the curly brackets). Thus, in KNesca f e ’s name space Vending Machine is a group definition, whose value is the set of public keys of all vending machines. In similar fashion; KNesca f e Distributors −→ {KD1 , KD2 }
KD1 Retailers −→ {KR1 , KR2 , KR3 } 4
(7) (8)
KD2 Retailers −→ {KR4 , KR5 , KR6 }
(9)
KR2 Customers −→ {KC1 , KC2 , KC3 , KC4 , KC5 , KC6 }
(10)
extended name
local name z }| { }| { z sub ject issuer }| { z z }| { KNesca f e Customers −→ KNesca f e Distributors Retailers Customers | {z }
(11)
KD1 ,KD2
|
{z
|
KR1 ···KR6
} {z
}
KC1 ···KC6 ···KCn
Because of such a unique naming structure under SPKI/SDSI, the binding remains valid even though the elements of its extended name change their actual public-key (i.e. Distributor and/or Retailer). The name certificates are used to give handy symbolic names to individual keys or groups of keys, and the authorization certificate can be used to authorise those keys or group of keys for some specific operations. sub ject(name)
issuer
z }| { z }| { KNesca f e co f f ee −→ KNesca f e Distributors | {z } auth tag
1 |{z}
(12)
delegation bit
Similarly, KD1 co f f ee −→ KD1 Retailers 1
(13)
KD2 co f f ee −→ KD2 Retailers 1
(14)
KR2 co f f ee −→ KR2 Customers 0
(15)
Equation 1-11, are the name certificates which are denoted by signed 4-tuples i.e. (K, A, S, V), whereas later equations represent the authorization certificates and they are denoted by signed 5-tuples i.e. (K, S, D, T, V) where, D is the delegation bit, if true, permits each key in subject to delegate the authorization further. SPKI/SDSI keeps notions of Name and Authorization certificates separate in order to allow a more accurate view of delegation. Name certificates only define local names (with one identifier); extended names are never defined directly; only indirectly. And a certificate does not invalidate others. 2.1.1 Threshold Certificates Threshold certificate is a feature in SPKI/SDSI that requires multiple principals to sign a request to get the authorization request honoured. It this special type of authorization certificate, unlike simple authorization certificates, the authority over the specified resource is given to a group of principals and a threshold or quorum (θ) is set. The value of θ determines the minimum number of principals required from an authorization group to collectively sign the authorization request. K close auction −→ θ3 {K1 , K2 , K3 , K4 , K5 } 0
(16)
Equation 16, depicts the threshold certificate shown in Figure 8. It represents the fractional delegation passed over close auction tag to the keys listed in the subject field. Each key in this certificate has received 1/θ (i.e. 1/3rd ) of the authority. Due to such a fractured delegation to the subjects, a signed request from a single principal will not be honoured by the system. Therefore, to exercises the authorization, a request must be signed by at least 3 principals listed in the subject field. (i.e. 1/3rd of the authority from each principal). The order of signatures does not matter. In case of delegable authority, each key listed in the subject field of the certificate can delegate only its fraction of the authority.
5
2.2 Access Control Access control is a process of regulating the use of resources against a defined access control policy and is essential for ensuring availability and security of the system resources. In its simplest form, access control can be treated as a list of permissions for authorised principals to access resources in an authorised way. The control is expressed through, what is termed as, Access Control List (ACL). ACL is an integral part of building secure systems (centralized/distributed) and specifying the security policy in general. ACL, as the name indicates, is a list of rules present with the resource controller, which the requester has to satisfy to obtain access to the resource in question. ACLs allow a principal (owner of the resource) to specify policy for principals (requesters) to access resources. In SPKI/SDSI, ACL is a set of authorization rules, each rule is an authorization or threshold certificate with an optional issuer field. If the issuer field is absent, it is assumed that the owner of the resource itself is the issuer. The ACL creator may allow the subjects on the entries to further delegate the authority. For example, consider an entry in the ACL on the Nesca f e coffee-vending machine as shown in Figure 4. (acl entry (subject (ref (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) Customers
))
(tag (coffee (cold 80ml:hot 100ml))) (delegate 0) )
Figure 4: ACL entry for resource “coffee” Briefly, the certificate shown in Figure 4, denotes the following access policy: KNesca f e co f f ee −→ KNesca f e Customers 0
(17)
That is, the members of KNesca f e Customers group can exercise the authorization but cannot further delegate the authority to other principals on their own. It is also possible to enforce rules wherein some quorum of principals are needed for ensuring access to a resource - this is handled through the threshold certificates.
2.3 Authorizations Under SPKI/SDSI In this section, we shall illustrate as to how authentication and authorizations are achieved using SPKI. We shall explain the working of SPKI framework with a sample scenario involving a restricted resource. We will continue with the “Nesca f e” example. Nesca f e has installed five SPKI-enabled vending machines (KV M1 , KV M2 , KV M3 , KV M4 , KV M5 ) at different locations to serve coffee to its authorised customers. Nesca f e has nominated two distributors KD1 and KD2 for this. Further, the distributors have a large number of retailers chain who will deal with the end users(in turn Nesca f e’s customers). All of Nesca f e’s customers have received the authorization to access the coffee vending machines via Nesca f e → Distributors → Retailers. The customers have to prove this authorization flow to the coffee vending machine before having coffee. The coffee vending machine will verify the claims made by customer and will serve coffee on successful verification. A SPKI server is running in conjunction with the coffee vending machine. To access the protected resource one must satisfy certain conditions (i.e. ACL entries). Equation 17, is the ACL for all the coffee vending machines. Once the requester authenticates itself and proves the authorization over the resource, a token signed by the server will be issued to the requester. By submitting such a token to the resource, the requester can access the protected resource. Some similar examples of such resource can be an on-line directory server, web pages or files on a ftp server, an electronic cheque book, smart card applications, and the list goes on. In short, any application that 6
demands a specific authorization from the requester to run the application can be molded into this system. Let us see how a Nesca f e customer generates the certificate chain proving his/her credentials to the coffee vending machines. When a customer is authorised for vending coffee from coffee vending machine, he/she will be given the necessary certificates which will be stored in $HOME/.sdsi directory. Lets narrow down our case study on the customer KC1 . Customer KC1 is the recipient of authority from retailer KR2 . KR2 is the recipient of the authority from dealer KD1 , which in turn is a recipient of authority from KNesca f e . Some of the certificates from KC1 ’s database are, KR2 Customers −→ KC1
(18)
KR2 co f f ee −→ KR2 Customers 0
(19)
KNesca f e Distributors −→ KD1
(20)
KD1 Retailers −→ KR2
(21)
KNesca f e Customers −→ KNesca f e Distributors Retailers Customers
(22)
The vending machines are equipped with necessary certificates and Access Control Lists. The ACL on vending machine 1 is, KV M1 co f f ee −→ KNesca f e Customers 0
(23)
When KC1 computes the closure over its set of certificates, following are the new inferences added to the linked list. KR2 co f f ee −→ KC1 0
[(19) ◦ (18)]
(24)
KNesca f e Customers −→ KD1 Retailers Customers [(22) ◦ (20)]
(25)
KNesca f e Customers −→ KR2 Customers [(25) ◦ (21)]
(26)
KNesca f e Customers −→ KC1
[(26) ◦ (18)]
(27)
Now, KC1 requests for coffee at vending machine 1. Vending machine replies with the ACL as challenge. KC1 takes the ACL and computes the closure again. KC1 checks for any inference which starts from Vending Machine 1’s public key and ends at KC1 . If such inference rule is present in the closure, KC1 submits the proof of this inference to KV M1 . The closure program running on Vending Machine 1 verifies the claims made by KC1 . On successful verification the SPKI server issues a token to KC1 . KC1 can get coffee by submitting this token to the vending machine 1. Following is the inference rule which principal KC1 has found in its closure. This rule starts from KV M1 and ends with KC1 . KV M1 co f f ee −→ KC1 0
[(23) ◦ (27)]
This is essentially a compact form of the following certificate chain; (23) ◦ (27) = (23) ◦ (26) ◦ (18) = (23) ◦ (25) ◦ (21) ◦ (18) = (23) ◦ (22) ◦ (20) ◦ (21) ◦ (18)
7
(28)
VERIFIER
B
B Satisfy ACL
Resource
C Request for ACL or Threshold certificates
PROVER A
Requester
D Send ACL (Challenge) SPKI / SDSI Server
C
E Look for a possible Certificate Chain (Proof) D
Closure Engine E
F I
ACL F Submit the Certificate Chains as proof
Closure Engine H
Certificates Name/Auth/Threshold
A Request for accessing the Resource
Certificates
G
G SPKI server will verify the Chains
Name/Auth/Threshold
H Send a signed token to the Requester I Submit the token to the Resource J Grant access after verifying
J
the signature on the token
Resource protected using the SPKI Architecture
Figure 5: SPKI Protocol Example
In Figure 5, the whole process is categorized in some systematic steps, each step denoted by an alphabet in capital. A flow-chart explaining steps involved in finding closure can be found in Appendix B. Additional steps involved, when the requester is not a member of any of the groups defined on ACLs: After receiving the set of ACLs from the controller of the restricted resource, requester has to satisfy any one of the Access Control mechanism. This will be trivial if requester’s key is directly listed in any of the ACL, or requester is member of a group mentioned in the ACL. Sometimes, the requester’s group might not be listed explicitly in the ACLs, but there can be a link from the groups listed in ACL to the group in which requester has membership. But the requester is unable to generate the certificate chain(proof) due to the missing link in between the groups. In such scenario, requester sends membership query to the owners of the groups which are listed in the ACLs. Owners of respective groups reply to the query with a member-list of principals or groups. With this newly available information, requester looks for the missing link(a certificate or set of certificates representing a name binding from any of the groups listed in ACL to any of the group in which the requester has membership). If the lookup for the missing link fails, the requester sends membership queries to the owners of the newly known groups. And the process iterates for a fixed number of levels or until a link is found, whichever finishes first. Membership protocol has two routines, Membership.Query and Membership.Cert(reply); ( Membership.Query: ( To: ( Principal: ... A ... ) ) ( Member: ( Principal: ... B ... ) ... ) ( Group: DAE_employees ) ( Credentials: ... ) ( Signed: ... ) ) ( Membership.Cert: ( Member: ( Principal: ... B ... ) ... ) ( Group: DAE_employees ) ( Reply: ) ( Hint: ) ( Signed: ... ) ) The Reply can be true or false or fail. If principal B is member of DAE employees group owned by principal A, the answer will be true. When the answer is fail, server may opt to reply with certain Hints which contains names of other groups where B can look for its membership status. A Reply containing false says that B is not a member of that particular Group.
8
2.4 Suitability of SPKI/SDSI as a Practical PKI While SPKI/SDSI has been founded on nice rationale and has several distinct advantages over other PKIs such as X.509 and PGP, there is a need to overcome some of the hurdles in building a practical PKI based on it. One of the most distinct disadvantages lies in building a key management system for a PKI based on SDSI/SPKI. In our aim to build a practical PKI, we look at some of the basic practical issues in the following without solely concentrating on the key management system. Let us consider the basic question of access control: Is principal X authorised to do Y? yes; provided the principal satisfies the access control policies using the available set of facts (certificates). Even though the answer looks natural, it is complicated as the proof verification leads to several questions. This aspect is analysed in the following: Issue 1: From the inability of the principal to satisfy the access control policy, can we conclude that the principal is unauthorized? Reasoning 1: In fact, the only conclusive answer for the above question is that the principal has not been able to find proof (or certificate chain). It is so because of the following reasons: 1. Firstly, SPKI/SDSI is a distributed system and the onus of proving authorization lies on the principal. Hence, it is the responsibility of the user has to build a chain of certificates inferring the flow of authorization from resource owner to itself. Thus, derivation of the certificate chain requires facts stated by other principals located in the environment that is distributed. Note that the certificate chain need not have to be unique. The failure of retrieving facts from other entities in the distributed environment hinders the proof generation. 2. Another common reason can be the change in resource’s access control policy with incomplete/inconsistent updates with the intermediaries (that receive authorization from resource owner and maintain group and/or threshold definitions on behalf of the resource manager). To overcome the above drawbacks without foregoing the underlying rationale for security, we need to build an access control mechanism that at least addresses following issues: 1. The access control mechanism needs to be flexible enough, so that a principal can approach the authorization verifier in all possible alternative ways. 2. While alternative proofs can be discovered in SPKI/SDSI it does not permit the authorization proof generated by non-SPKI/SDSI method; i.e. an authorization proof (not necessarily of type SPKI/SDSI) that is equivalent to an acceptable one, should also be acceptable. For example, a SPKI/SDSI certificate from a trusted CA stating the membership of its subject to adult group is acceptable to SPKI/SDSI but the same inference is also possible to be obtained through the swiping of the driving license or voter-id (provided the hardware allows it), which SPKI/SDSI doesn’t allow. In fact the principal might have received the SPKI/SDSI certificate from the CA by showing its driving license or voter-id! 3. SPKI/SDSI’s authorization delegation procedure is boolean in nature, which takes control out of resource owner’s hand (up to some level) if delegated to betraying entities. There should be a provision to tame the un-authorised explosion of authorizations. 4. Using threshold certificates, consensus issues amongst a group of principals can be solved, but when it comes to address the consensus issues amongst the set of such groups the access control policy becomes very lengthy and cumbersome. Though, perhaps, we could achieve some of the above features through some system-specific implementations, we are looking for a flexible access control specifications that can easily specify: • complex security policies. • making it possible to use the provisions of PKI systems such as SPKI/SDSI, X.509, PGP etc., in an integrated way so that the scope of the system can be enhanced and the underlying trust mechanisms can be effectively used. In the following section, we shall highlight our access control specifications and other issues. 9
3 Design and Implementation of ROADS We have built a prototype PKI called ROADS based on SPKI/SDSI. ROADS supports in general the features of SPKI/SDSI including group membership certificates and threshold certificates. However, we have tried to integrate authentication mechanisms into it (resulting into flexi-ACL) for addressing dynamic security requirements and also helps in addressing context-aware policies. After describing the access control policy specification under flexi-ACL, we shall discuss features such as authorization, delegation, and other specific features of ROADS.
3.1 Implementation Details of ROADS The implementation is done using gcc on GNU/Linux platform. The core part of the implementation is a program (closure-engine [9]), which updates the certificate database temporarily poured into a linked list. Possibility of inferring a new certificate (or binding) from two or more existing certificates triggers updation of the linked list. This process continues till there is no set of rules (certificates) leading to an inference, which already has not occurred or not present in the linked list. Our implementation conforms to the definitions and properties discussed in “Certificate Chain Discovery in SPKI/SDSI” [9]. Our implementation also accommodates the threshold rules/certificates. The crash-proof execution of the closure-engine demands unambiguous set of input certificates, which forced us to eliminate possible induction of ambiguity from naive-user side while administrating local name space in its domain. We have designed a robust rule-based interface which helps user in name space management and thwarts ambiguities by checking the input against the rules embedded into the interface. Apart from this, ROADS gives a facility for resource administrators to enforce a policy under which requester are forced to provide a authorization proof that proves a particular role that requester should exercise while accessing the resource under question. ROADS also facilitates requesters to submit a proof (among the all possible proofs) complying to particular role, thus addressing privacy issues. ROADS also provides a mechanism to control the depth of delegated authorization. Such a facility is useful in building trust management frameworks; generally trust degrades at each delegation depth. A pseudo-code for this algorithm is provided in Appendix A, and C.
3.2 Efficient Interfaces for ROADS-enabled Applications Out of the various interfaces that would make the system user-friendly and efficient, we shall discuss i) Use of Tokens as authorization and ii) Maintenance of certificates through web-forms in the following. 3.2.1 Using Tokens as Authorization To avoid the whole authorization flow verification of each request at the resource (here, the coffee-vending machine), one can outsource the verification process to an affiliated trusted computing node. This computing node takes the responsibility to verify the authorizations and on successful verification, issues a signed token to the requester, which can be redeemed against the coffee at the coffee-vending machine. Thus, the coffeevending machine (resource) has to only verify the authenticity of the token, which can be hard-wired with some flexibility of storing and updating keys or encryption programs. Otherwise, the resource needs moderate computing power and flexible programming options. Tokens are application-specific objects, signed by their issuer. The object contains necessary information and instructions for accessing the restricted resource. The application server, which controls the restricted resource, will allow the requester to enjoy its authorization over the resource if it provides a valid token issued by an affiliated token-issuing server. The job of the resource controller will be to verify the affiliated server’s signature over the token (token-issuer’s public-key is supplied to resource controller in advance). Proper access restrictions, as specified in the token object, will be applied. Using tokens in place of real authorization chains makes the system more portable and efficient. Since the validation of actual authorization chains and minting of tokens is done by a trusted third party, resource control has to only verify the tokens received. Figure 6, shows a token redeemable against coffee at coffee-vending machine, issued to the principal listed inside the subject field. Sometimes, unprivileged users borrow the tokens from other users and enjoy the privileges. One can restrict this by embedding extra information into the token. The extra information needed can be a unique set of identifiers which user easily can’t change or reluctant to give it to others. To avoid double-spending, we
10
(token (issuer (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) (subject (public-key rsa-with-md5 (e |PlrQdtVwh9f4rJIQVXPj|) (n |HenP74ghP9rFZ0gAIYZ5q9yAiskDJwASi6rECaEQq&ZyMZeIAEHATUI53hK=|))
)
)
(tag (coffee (cold 80ml:hot 100ml))) (not-before "2002-01-01_09:00:00") (not-after "2002-01-01_09:03:00")) Figure 6: coffee token redeemable only at Nesca f e vending machines have kept the life-time of the token roughly equal to the time required to honour the request. So that by the time the request gets honoured the token expires, assuming the system does not crash while processing the request. We look at this facility as an application performance enhancer. Since it reduces the load of verification from the actual resource controller by outsourcing the process to a trusted affiliated ROADS server. 3.2.2 Maintenance of certificates through Web-forms As the volume of certificates grow in the user’s database, manual assignments of local names may invite some ambiguities which will lead to errors in certificate chain generation process. Therefore we felt the need to automate this process with the help of certain rules. The interface helps users to maintain their certificates easily. It stores all the certificates (issued or received) of a user in user’s $HOME/.sdsi directory on a UNIX like system. This interface allows the user to issue certificates (name or authorization), write ACLs, sign objects and verify signatures. While issuing certificates, the web-form rules make sure that the updated certificate database will be unambiguous. It has a provision to import certificates from other users. As a generalisation step, we have merged the authorization and threshold certificates into a single structure. Since, we realised that an authorization certificate is nothing but a threshold certificate having only one principal in its subject field and the threshold value (θ) set to 1.
3.3 flexi-ACL Access control specification corresponds to a systematic way of specifying rules for accessing the resources as well as to restrict the delegability of permissions to intended parties. Group membership and threshold certificates are two mechanisms that are widely used for access control. Such schemes are convenient while considering only single administrative domain or a closed environment (where all the environment variable are readily available during decision making phase). While addressing access control policy issues for a larger set of principals belonging to distinctly separate domains or organizations or groups, we lack the expressive power to narrate all the access control policy issues. In practice, it is cumbersome to employ all authorizations through group memberships, as different administrative domains may have different mechanisms to authorise their users. So, while writing access control policies spanning across different administrative domains, one should make use of existing authentication and authorization mechanisms instead of molding them into group memberships (this requires issuance of new certificates across organisations, etc.). This will also make the system scalable and user-friendly without sacrificing security. In the following, we provide an access control specification structure called flexi-ACL. It is a generalized form of access control, that has provisions for all hybrid types of access control mechanisms and also permits specifications of alternative or a priori anticipated emergency measures of access control of resources. In the
11
terminology of SPKI/SDSI, it permits the requester (prover) to try other possible alternative ways to derive the authorization if it exists, when one form of authorization mechanism fails. The enriched system expresses access control policies in a simple, effective and an easily audit-able way. In the following we shall provide an abstract description of flexi-ACL. Before we consider the specification of flexi-ACL, let us consider the various components from which the specification of a flexi-ACL is composed. The main components used in flexi-ACL are: 1. Types of authentications used: This attribute is referred through the keyword entry-type. The possible types that are currently incorporated in flexi-ACL are given in Table 1. Each of the entity-type entry-type sdsi login QA biometric other-ID
Description asks the requester to prove group membership or threshold conditions for a given server, perform login-password based authentication interactive Question Answer session when physical presence is required (provides highest trust factor) other types of identity proofs e.g. driving-license (moderate trust factor) Table 1: Various entry-types supported by flexi-ACL
itself has a structure that needs to be adhered to. This becomes clear during the description of the following item. 2. Rules of the acl-types: In the flexi-ACL structure, this is captured by the keyword entry-type. Different PKIs as well as different established methods of access control have different ways of formulating the rules. For example, in the case of SPKI/SDSI, the way the rules are specified is illustrated below: (acl rule-1 (entry-type sdsi (subject (ref (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|)) group-logic-programmers)) (tag (http * prefix http://dlib.computer.org/co/co2002/)) (delegate 0))) The above access control rule (named rule-1) can be interpreted as follows: A principal has to prove its membership to the group group-logic-programmers to get access to the files stored in directory /co/co2002/ at http://dlib.computer.org. If the principal cannot be established, the request will not be honoured. Having described the structure of a rule, one needs to explain the mechanism of realization. In the case of SDSI, this is done through a protocol (c.f. [10]). In the protocol, an abstract function Membership.Query has been defined that can take one of the following three values; TRUE : if requester is a member of the group, FALSE : if requester is not listed in the group member definitions, FAIL : when the group-owner is unable to decide requester’s membership, returns a plausible (optional) Hint. For our purpose, we need the value to be boolean. Thus we avoid the third case of FAIL by interpreting FALSE value as follows: The requester has tried all (finite) possibilities and failed to provide proof of membership. Let us consider other types of access controls; A. entry-type is login: Rules of this type are based on the password authentication mechanism. For a 12
given server, if the requester performs successful login-password authentication, the rule returns true, else false. (acl rule-2 (entry-type login (server mailhost.university.edu))) B. entry-type is QA: This rule collects answers for the given set of questions. It returns true on on providing correct answers by the requester (prover), otherwise returns false. (acl rule-3 (entry-type QA (URL-submit https://10.0.0.1/cgi-bin/validate (method POST) (question roll-number ) (question PIN )))) Expression A AND B A OR B
Description returns 1; when E(A)=1 and E(B)=1, else returns 0 returns 0; when E(A)=0 and E(B)=0, else returns 1
Table 2: flexi-ACL expressions and their description 3. Expressions: As the rules return boolean values, we permit expression of rules as given in Table 2, below. Given a set of rules, one can form suitable expressions using operators AND, OR provided under flexi-ACL. For example, if A and B are two distinct rules and let E(A) and E(B) be their respective evaluation methods, which return boolean value. Table 2, gives some expressions and their respective outputs. An expression always returns a boolean. The inclusion of operator NOT is being analysed from the point of view of expressiveness and implementation. 4. acl-block: An acl-block is a block encompassing an expression of access control rules described above. A typical structure is shown below: (acl-block (acl rule-2 (entry-type login (server mailhost.university.edu))) OR (acl rule-4 (entry-type sdsi (ref: university students))))) This acl-block is composed of rules: rule-2 and rule-4. The acl-block eventually returns true when either of the rules returns true. In the implementation it is treated as OR (conditional OR) 5. flexi-ACL Structure: The syntactic S-expression structure of a typical flexi-ACL access control specification is shown below. In the structure shown, a: entryname is the name given to the structure, b: policy is a keyword and quorum(n) indicates that at least n acl-blocks specified must return true. In other words, the number of acl-blocks specified must be at least n (acl entryname (policy quorum(n) (acl-block (rule-1) AND (rule-2) AND ((rule-3) OR (rule-4)) AND (rule-5)) (acl-block 13
(rule-6) OR (rule-7) AND (rule-8)) (acl-block (rule-9)))) Note: The name entryname can be used in the place of rules specified earlier. However, recursive invocations are not permitted. flexi-ACL Example: (acl e-ballot (policy quorum(1) (acl-block (acl voter (entry-type sdsi (ref: govt state1 citizen age-over-18)))) (acl-block (acl social-security (entry-type QA (URL-submit https://10.0.0.1/cgi-bin/ss_number (method POST) (question social-security-no )))) AND (acl driving-licence (entry-type other-id (swipe drv-card)))))) This is an access control policy for electronic voting. There are two acl-block and the quorum is set to 1. To cast a vote requester must satisfy any of the two acl-blocks. Other things are self-explanatory.
4 Applications of ROADS We have used the flexible features of ROADS for various applications of e-commerce such as e-auctions, epayments [11] and several privacy and anonymity aspects some of these aspects are briefed in the following sections. Because of the key features like separate authentication and authorization, flexible ACLs using groups and threshold certificates and tokenization, etc, we found application of ROADS in micro-payment [11], distributed auction system - SeTiA [6] and various facets of privacy. Some of these applications are described below.
4.1 Consensus in distributed environment using threshold certificates In distributed environment, there are situations when participating entities are not allowed to perform or execute certain tasks on their own; but they will be suggested to do it collectively with similar other authorised entities. For example, distributed decision making, secret sharing, withdrawing money from a joint bank account, etc. In general such type of scenarios, which need a consensus, can be addressed effectively with the help of threshold certificates. Such a scenario in SeTiA is described in the following using Figure 7:
Problem : In multi-site auctions, there is a need to arrive to a consensus amongst the participating server for the closing time of the auction. An auction has to be closed after keeping open for reasonable time period. Since the system is distributed over the network, there should be a framework which provides the closing time of an auction to all participating servers. Solution : This problem can be addressed in two ways. One, by assigning a central server which will issue instructions to the participants. But this involves the threats like breaching the trust or single point breakdown and other inherited problems that any centralized system will have. Another solution is to let the participants decide amongst themselves when to close the auction or to let at least k out of n authorised participants to decide the closing time of the auction. We solved the problem of arriving at a consensus over closing time
14
(close)K1 (close)K2 (close)K5
K1
(close)K1 (close)K2 (close)K5
AS1
AS2
(close)K1 (close)K2 (close)K5
(close)K1 (close)K2 (close)K5
K5
AS5
K2
K3 (close)K1 (close)K2 (close)K5
AS3
K[i] = Private−Key of server i K4
AS[i] = Auction Servers
AS4
Figure 7: Closing multi-site auctions using Threshold certificates
of auctions using the threshold certificates. Also, the use of threshold certificates for distributed auctions improved the overall security of the setup. We will explain the details below: Figure 8, shows the threshold certificate issued to the 5 servers in a multi-site auction system having public keys K1 , K2 , K3 , K4 and K5 . Given the facility to broadcast the signed requests and receiving the broadcasts of other servers, the distributed consensus problem can be solved. This facility has the capability to count the total number of signed broadcasts by other peers and upon receiving a threshold number of signed requests, it verifies the authenticity of the requests. Upon successful verification, it initiates the process of shutting down the particular type of auction process running on different servers. This routine is incorporated with the closure computing and certificate chain verification mechanism, so that it can verify the authorizations, authenticity and validity of the signed requests. The threshold certificate issued to all the auction servers is shown in Figure 8. This authorization certificate will let the auction servers to exercise their partial rights to close the auction. For this, the auction server has to produce a certificate chain showing the flow of authorization over close auction service. The certificate gives 13 rd of the authority to all participating auction servers for close auction service. This means, for closing the auction, consent of three or more authorised auction servers is needed. All the auction servers whose public key is listed in above certificate will be having this certificate in their local certificate database, apart from the other certificates in it. If the request is signed by less than θ principals, it will not be honoured. The keys enlisted in the subject part of the threshold certificate are the real keys of the servers. Complying with auction properties as specified in SeTiA [6], an auction server desires to close down the auction if no new bids arrive for certain time period, eventually sending a signal (signed request) to all other participating servers in the auction. Every server participating in the auction process is running in conjunction with a pool program. The pool program will not invoke the auction closing routine until it receives ≥ θ valid requests. As soon as the threshold gets satisfied all the servers have to close the auction at the negotiated time, taking into account the network delays, etc, to broadcast the signed close auction requests. Thus, our implementation is an improvement over The Design and Implementation of a Secure Auction Service by Franklin and Reiter [12] in terms of readily available security infrastructure at hand. The threshold certificate contains public-keys of all other participating servers, so that the key can be used for secure communication between nodes. Because of the signed requests, the servers cannot repudiate the agreements or consensus that have been reached in the past. Moreover, this implementation is as fault tolerant as Franklin and Reiter’s.
4.2 Anonymity, Pseudo-anonymity, Proxy-authenticated service, Privacy 4.2.1 Anonymity A security service is said to be anonymous if it prevents the disclosure of information that leads to the identification of the end users. Anonymity refers to the complete absence of identification data in a transaction. 15
(certificate (issuer (public-key rsa-with-md5 (e |NFGq7E3wh9f4rJIQVXhS|) (n |d73874ghP9rFZ0gAIYZ5q9y6iskDJwASi5rEQpEQq8ZyMZeIZzIAR2I5iGE=|))
)
(subject (public-key rsa-with-md5 (e |asdfre4459f4rJIQVXhS|) (n |Si5rEQpEQq8ZyMZiskDJwASi5rEQpEQiskDJwASi5rEQpEQasdf45435467=|)) : K2 K3 K4 : (public-key rsa-with-md5 (e |t234scu4gLh9f4rJIQVX|) (n |gAIYZ5q9y6iskDJQq8ZyMZeIZzIA5q9y6iskDJwq9y6iEQpkDJQq8ZskDae=|)) (tag (close_auction))
(delegate 0)
)
(threshold 3)
(not-before "2002-01-01_09:00:00") (not-after "2003-01-01_09:00:00")) Figure 8: Threshold Certificate issued to the Auction servers The key characteristic of an anonymous transaction is that the specific identity of one or more of the parties to the transaction cannot be extracted from the data itself, nor by combining the transaction with other data. Functional anonymity can be achieved by inducing a trusted third party into the system. ROADS serves the purpose of trusted third party. This trusted server is willing to mint tokens for the requesters, who will satisfy the Access Control rules defined on the server. We shall illustrate the same using the following scenario. (acl rule (entry-type sdsi (subject (ref: Associate_Servers India Users)) (tag (ftp write(* prefix //www.vigilance.gov.in/report_us/))) (delegate 0))) This access control rule checks the requester’s membership for issuer’s Associate Servers Indias Users group. Requester satisfying this ACL rule will get a token signed by the ROADS server. This token is the passport for the requester to log into ftp://www.vigilance.gov.in and uploading files into report us directory. The only thing the ftp server has to do is to verify the signature on the passport (token). On successful verification, it allows the requester to enjoy the privileges mentioned in the passport. The trusted third party is responsible for verifying the authenticity and authorizations of the incoming requests and in-turn it issues a signed token to the requester, depending upon the authorizations the requester possesses. Once the principal acquires such a token it does not need to reveal its credentials or other information to access the resource. By producing the appropriate token for appropriate service, users can enjoy anonymity. For certain applications where user has to be authenticated each time or in certain cases to avoid double-spending, one can integrate one-time-pads with the mechanism.
16
Application: In sealed-bid auctions the anonymity of the bidders is very important. If we replace the traceable entities like user certificates or signatures with a token which is issued by a trusted neutral party, a comfortable level of anonymity can be achieved. In our implementation, there is a SPKI server listening for user requests for tokens. SPKI server throws challenge to the requester with listed ACL. The rule subjected for sealed-bid auctions is, (acl rule (entry-type sdsi (subject (ref: Associate_Servers Users)) (tag (auction sealed-bid(https://www3.auctions.com))) (delegate 0))) If the requester proves itself credible for that particular type of task or action, SPKI server issues a signed token to the requester. Requester can use this token for intended purpose. The token obtained by the requester satisfying above ACL rule will be accepted by http://www3.auctions.com without any further verification, except verifying the trusted party’s signature on the token. By doing this, the auctioneers need not ask the bidders any details as far as the bidder produces a valid token for appropriate service or transaction. In brief, eligibility authentication is what we require instead of user authentication (which necessarily involves the provision of evidence of the identity of the individual) for achieving anonymity. 4.2.2 Pseudo-anonymity (Pseudonymity) A transaction is pseudonymous in relation to a particular party if the transaction data contains no direct identifier for that party, and can only be related to them in the event that a very specific piece of additional data is associated with it. The data may, however, be indirectly associated with the person, if particular procedures are followed. To complete such procedure, help of one or more trusted third parties is taken who have helped the user achieving anonymity. When the entity desiring anonymity does user authentication with the trusted third party, it will receive a token (pseudonym). This token can be used to do the eligibility authentication, wherever necessary. A pseudonym is an identifier for a party to a transaction, which is not, in the normal course of events, sufficient to associate the transaction with a particular human being or active entity. Sample Scenario : Cipla, a pharmaceutical company, sells its AIDS vaccine Triomune-30 in concessional rates to the people in Africa. To avail this concession, the requester has to satisfy certain conditions like he or she has to be from a country in African continent. Due to some reasons, the buyer wants to remain anonymous. If the near-perfect anonymity is given to the buyer, anonymity can be misused by the users to divert the cheaply purchased Triomune-30 in Africa to the other regions, where the rates are quite high. On the knowledge of such a discrepancy, there should be a mechanism to find out the user who is misusing the concessions. The access control rule on the trusted ROADS server is, (acl entry (entry-type sdsi (subject (ref: Associate_Servers African Users)) (tag (drug Triomune-30 concession(Country_Continent(Africa)) (https://www.cipla.com/buy/))) (delegate 0))) The requester has to prove its membership to Issuer’s Associate Servers African Users group to obtain the pseudonym. This pseudonym is used at https://www.cipla.com/buy/ to purchase the drug. The trusted third party must maintain a cross-index between the indirect identifier and the person’s real identity. It must apply appropriate technical and organizational security measures, and divulge the link only in circumstances specified under legal authority, such as contract, legislation, search warrant or court order. A secret sharing mechanism can be involved in this setup to avoid breach of trust by the trusted third party and the single access point failure. Whatever user produces to the trusted third party to gain pseudonym, is essentially a secret. If we keep parts of the secrets on various trusted servers such that no trusted party collude with the adversary and divulge the sensitive information. For example, to get the pseudonym from ROADS server, the user submits all essential data (like age, nationality, bank’s name etc.) to the server. This data 17
is meant to be kept secret to respect user’s privacy. If all the data pertaining to any user is kept on a single server, the privacy of the user can be jeopardised. So user may think of distributing its information over k trusted servers. Thus the secret (S ) is shared between k trusted servers, while the quorum[13] is set to q. The knowledge of quorum q or more shares allows S to be easily computed; knowledge of q -1 or less pieces reveals no information about S. To trace the identity of the entity in question, certain number (q ) of trusted parties have to come together and share their secrets with each other to compute the original secret (S ). 4.2.3 Proxy bidding In real world situations, we delegate our authority to others to accomplish the task on our behalf. While doing this, we pass on only the required authorization and certain instructions. In auctions, like English and continuous-double auction, bidders make use of software robots to bid. By issuing an authorization certificate to the software robot, bidders are enabling the software robots to bid on behalf of the actual bidder. Following is the authorization tag that regulates the behaviour of the robot while exercising the authority. (tag (* linear 2 max(1000))) (delegate 0) With these specific fields in the certificate, the robot is allowed to bid on behalf of its issuer. The additional instructions for the robot are to increase the bid amount linearly by 2 Rupees up to the maximum limit of 1000 Rupees. 4.2.4 Privacy The right of an entity (normally a person), acting on its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share information about itself with others. Sample Scenario : When a person has satisfied all the prerequisites to enter into a foreign country, he or she need not to produce any irrelevant information other than the minimal things like passport number and visa etc. The things like traveller’s age, profession, qualification etc. and other personal information should not be revealed for any commercial or other purpose until and unless the local law explicitly intends so. Since ROADS allows to achieve a particular authorization in different ways i.e., a requester can produce different certificate chains to achieve same authorization, it is up to the requester which chain to submit. So, it is possible for requester to gain a desired level of privacy.
5 Discussion In this paper, we have discussed the design and implementation of a role-based authorization and delegation system. We have used a flexible access control schemes to allow for ease of usage without foregoing security. One of the distinct features of ROADS has been the incorporation of the flexible access control specification flexi-ACL in the SPKI/SDSI system. In our analysis and experience with the prototype, we have found it to be extremely useful in building e-transaction system that are secure and user-friendly. We have also illustrated the application of ROADS for realizing the closure of auction time for a distributed auction system in a consensus way as well as other privacy and anonymity issues through the deployment of ROADS. One of the difficulties in SPKI/SDSI has been realization of an efficient key-management system. We are working on a simple key-management system with features such as key-generation, key-distribution, keyinstallation, key-backup, key-revocation, enforcing some kind of hierarchy that could be specified through flexi-ACL kind of mechanisms. Further extensions to ROADS are possible for realising secure applications in distributed environment. For example, in secure distributed file-system, mobile agents, grid infrastructure, trust management and several other e-commerce applications.
Acknowledgments The work was done under the project supported by Department of Information Technology (Ministry of Communications & Information Technology), Government of India, New Delhi.
18
References [1] Warwick Ford and Michael S. Baum. Secure Electronic Commerce: Building the Infrastructure for Digital Signatures and Encryption, Second Ed. Prentice Hall, 2002. [2] Russell Housley, Tim Polk, Warwick Ford, and David Solo. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. RFC 3280, IETF, 2002. [3] Ronald Rivest and Butler Lampson. SDSI – A Simple Distributed Security Infrastructure. Presented at CRYPTO’96 Rumpsession, 1996. [4] Carl M. Ellison. SPKI/SDSI Certificate Documentation. 2002. http://world.std.com/˜cme/html/spki.html. [5] Vishwas Patil and R. K. Shyamasundar. Towards a Flexible Access Control Mechanism for ETransactions. In the International Workshop on Electronic Government, and Commerce: Design, Modeling, Analysis and Security (EGCDMAS-2004), pages 66–81. INSTICC Press, August 2004. [6] Mehul Dave Vivek Borkar, R.K. Shyamasundar. Design of a Secure Multi Auction System. 2002. See http://www.tcs.tifr.res.in/˜shyam/setia.ps. [7] ASN.1: Abstract Syntax Notation One, ITU - International Telecommunication Union, 1997. [8] Rivest. S-Expressions. See http://theory.lcs.mit.edu/˜rivest/sexp.txt. [9] Dwaine Clarke, Jean-Emile Elien, Carl Ellison, Matt Fredette, Alexander Morcos, and Ronald Rivest. Certificate Chain Discovery in SPKI/SDSI. Journal of Computer Security, 9(4):285–322, 2001. [10] Ronald L. Rivest and Butler Lampson. SDSI - A Simple Distributed Security Infrastructure. April 1996. See http://theory.lcs.mit.edu/˜rivest/sdsi10.ps. [11] Ronald Rivest and Adi Shamir. PayWord and MicroMint: Two simple micropayment schemes. In Security Protocols Workshop, pages 69–87, 1996. [12] Matthew Franklin and Michael Reiter. The Design and Implementation of a Secure Auction Service. IEEE Transactions on Software Engineering, May 1996. See http://dlib2.computer.org/ts/books/ts1996/pdf/e0302.pdf. [13] Erik Warren Selberg. How to Stop a Cheater: Secret Sharing with Dishonest Participation. CMU-CS93-182, July 1993.
A
Choice of data structures
Each node of the linked-list (used to compute certificate closure) is having following data-structure. We have clubbed all sort of certificates in a common skeleton. struct L { char K[K SIZE]; char A[A SIZE]; char T[T SIZE]; }; struct R { char S[S SIZE]; int D; int theta; }; struct cert { char cert type; unsigned int cert num; struct L *LHS; struct R *RHS; unsigned int derived from; unsigned int composed by;
/* Delegation */ /* Threshold */
/* Issuer /* Subject
19
*/ */
unsigned int valid from utc; unsigned int valid upto utc; struct cert *next;
/* valid from */ /* valid upto */
} node;
Every certificate is a binding between the issuer’s key to the subject, which can be either a key or an extended name with or without delegation depending on the type of certificate. Our data structure accommodate all such entities. The character variable cert type is used to identify the type of certificate and what rules are applicable to it while running the closure. An unsigned type of integer variable cert num is used for numbering the certificates temporarily; this numbering is useful to decide how a particular certificate is generated. Each node in the linked-list is accompanied by two state variables derived from and composed by. When a new certificate is composed, these two state variable keep the information of the two parent certificate(nodes) taking part in the composition. This information is used while traversing backward to generate a certificate chain. For the original set of certificates C which are present in the $HOME/.sdsi/ before starting the closure engine, the state variables are assigned to 0.
B Steps to Compute Closure With the help of our closure program, one can uniquely derive the path or the intermediate steps how a new certificate has been inferred in C# . In this section, we will take a look at the construction of a certificate chain with the help of Figure 9. START
ABORT
Read Certificates from $HOME/.sdsi and add to the Linked List L
ERROR: No input certs
Remove invalid certificates from L
Y Filter out all irrelevant auth certificates i.e. (T = desired T) is false
Replace the Threshold certs with dummy auth certs
L = NULL ? (empty ?)
N
Using Compatibility matrix and reducing certs, compute closure and update L
From L, remove all name certs and all auth certs whose subject is not a single key
Remove all certs from L having Kj K* and a dead ticket on the right
Mark all certs in L having their subject from K*
Count number of keys from K* marked
L = NULL ? (empty ?)
Y
ABORT
N
N Count is greater than or equal to theta ?
Y
SUCCESS
Figure 9: Certificate Chain Generation
Principals maintain their certificate database up-to-date in $HOME/.sdsi directory with the help of the web-forms provided under ROADS. Before starting the closure computing routine, all invalid(outdated) and 20
C1 Name Name Name Auth 0 Auth 0 Auth 0 Auth 1 Auth 1 Auth 1
C2 Name Auth 0 Auth 1 Name Auth 0 Auth 1 Name Auth 0 Auth 1
C3 √ × × √ × × √ √∗ √
Table 3: Certificate Compatibility Table the authorization certificates having irrelevant authorization tags are removed from the linked list. Thus we will be left with a linked list whose each node is a certificate from $HOME/.sdsi. With each node, we have encapsulated three additional unsigned integers(cert num, derived from, composed by). These variables will be useful while giving the proof of certificate chain discovery. After checking the list for emptiness, the closure computation routine is invoked, if the list is not empty. In this step all possible valid certificates that can be inferred from C will be added to the list and the pointer to the list is returned as C# . Then remove all the name certificates from the linked-list. Also remove all such authorization certificates from the list whose subject is not a single key, since such certificates are not going to help us in deciding whether there is a path from Self −→ K∗ . (Self means the controller of the resource and K∗ is the requester’s key). Also the certificates having their subject other than a subject from K∗ won’t help us again, so remove them. Check the list for emptiness again, just to see whether any authorization certificate or certificates(in case of threshold certificates) satisfies Self −→ K∗ . Then mark the subjects which we are looking for, that is the subjects from K∗ . If we are looking for threshold subjects, it makes sure that threshold number of principals receive the authorization from the resource owner. If the threshold condition gets satisfied, the program returns the proof of the certificate chain generation. Table 3, gives the type of inferred/composed certificate C3 , where C3 = C1 ◦ C2 . Basic Complexity Measures: The running time of the certificate chain discovery algorithm is bounded by the size |C# | of the name reduction closure C# . If the initial set of certificates C is unambiguous, the running time of the certificate chain discovery algorithm is bounded by O(n2 l ).
C
Is principal X authorized to do Y, under condition Z?
To access a protected resource, a client must present to the server a proof that the client is authorized; this proof takes the form of a “certificate chain” proving that the client’s public key is in one of the groups on the resource’s ACL, or that the client’s public key has been delegated authority (in one or more stages) from a key in one of the groups on the resource’s ACL. But there can be instances under which the resource owner may not like to accept proofs that contain more than certain number of authorization jumps (each delegation causes unit increase in depth of delegation). Also, there can be instances under which the resource owner would not accept proofs that include a principal (authorized with delegation flag set to true) who is not conforming (misbehaving after obtaining the authorization) to the policy under which it has obtained the authorization. We provide a mechanism using which the resource owner can mention its constraints using which the authorization decisions will be performed. Let us briefly navigate through the whole process.
C.1 Definitions 1. K denote the set of public keys. 2. A denote the set of all possible identifiers. 3. N
L
denote the set of all local names.
4. N L (K) denote the local name space of key K. 21
5. N
E
denote the set of all extended names.
6. N E (K) denote the set of extended names beginning with key K. 7. N (K) denote the name space of key K (set of all names; local or extended). 8. T denote a term; either a key or a name. S T =K N 9. V C (T ) denote the value of a term T w.r.t. a set C of certificates. The value of a term is a set of public keys, possibly empty. V C (K) = {K} for any public key K and any set C of certificates, i.e. a constant expression evaluating to itself (as a singleton set). 10. A name certificate C = (K, A, S,V ) (intuitively, defining local name K A in terms of subject S) should be understood as a signed statement by the issuer asserting that V (K, A) ⊇ V (S)
that is, every key in the value V (S) of subject S is also a key in the value V (K, A) of local name K A. 11. The value of an extended name is implied by the values of various related local names. The value of an extended name KA1 A2 . . . An is defined recursively for n ≥ 2 as: V KA1 A2 . . . An = { K 00 : K 00 ∈ V (K 0 An ) for some K 0 ∈ V (KA1 A2 . . . An−1 )}
12. A name certificate C = (K, A, S,V ) in the form of a rewrite rule; KA −→ S
K A −→ T N L −→ T
13. Evaluating the expression V C (T ); i.e. value of term T will give a set of keys∗ or a null value. 14. Suppose C1 is a rule of the form (L1 −→ R1 ), and suppose C2 is a rule of the form (L2 −→ R2 ), where (L2 is a prefix of R1 ). That is, R1 = L2 X for some (possibly empty) string X. Then we define the composition of rules C3 = C1 ◦ C2 as C3
= C1 ◦ C2 = L1 −→ (R1 ◦ C2 ) = L1 −→ R2 X.
We say that we have rewritten C1 (using C2 ) to obtain C3 . If L2 is not a prefix of R1 then C1 ◦ C2 is undefined. 15. We say that certificates C1 = (L1 −→ R1 ) and C2 = (L2 −→ R2 ) are compatible if their composition C1 ◦ C2 is defined, that is, if L2 is a prefix of R1 . 16. If C is a set of certificate, we define the set C + , called the (transitive) closure of C , as the smallest set of certificates that includes C as a subset and that is closed under composition of certificates. 17. C = (L −→ R) is said to be reducing if | L | > | R |, where | X | denotes the length of sequence X. 18. The name-reduction closure of C # of C is defined to be the smallest set of certificates containing C and closed under “name-reduction” (rewriting with reducing certificates). That is, if C # contains a certificate C1 and it also contains a (right-) compatible reducing certificate C2 , then C # must also contain C1 ◦ C2 . 22
C.2 Closure Algorithm 1. Initialise C 0 to be the input set C . 2. As long as C 0 contains two compatible certificates C1 and C2 such that C2 is a reducing certificate and C1 ◦ C2 is not yet in C 0 , add C1 ◦ C2 to C 0 . 3. Return C 0 as the computed value of C # . • Create a directed graph G = (V, E) by creating a vertex v for each local name or key appearing in C , and an edge from vertex L to vertex R if C contains a name cert of the form: L −→ R. • Then ∗
V C (T ) = { K : (K ∈ K ) ∧ (T −→ K)} ∗
where T −→ K means that there is a directed path from T to K in G.
C.3 Modified structure of node struct node v { struct Key { ---------------------------------------------------}; struct Name-Key { char identifier; char delegation_flag; }; struct node *composed_from; struct node *composed_by; }; struct constraints Z { int delegation_depth; struct Key *Array[i]; };
C.4 Modified Certificate-Chain Discovery algorithm 1. Principal X has set of certificates C 2. X requests for Y 3. Y responds with a challenge containing the ACL and constraints Z 4. After analysing ACLs, X obtains sufficient additional certificates; if necessary 5. Certificate-Chain Discovery Algorithm (a) Remove useless certificates from C (b) Compute the name-reduction closure C # of C 0
(c) Remove all name certificates from C # to obtain C 0
(d) Remove useless authorization certificates from C to obtain C
00
(e) Set up a graph with one vertex for each key, and an edge from Ki to K j if there is an authorization 00 certificate C in C (f) Use DFS to determine if there is a path from Sel f (Y) to the requester’s (X) key. If not terminate with failure 23
(g) And if there exists a path, reconstruct the certificate chain from the information computed in previous steps 6. Check for validity of Z over the Certificate-Chain path (a)
struct Z { int delegation_depth; cert principal[]; };
(b) Z can be a NULL value variable, in such a case our algorithm becomes the classical CertificateChain Discovery algorithm with unrestricted delegation depth (c) If Z is non-NULL; delegation depth specifies certificate-chain proof’s maximum permissible delegation depth (d) And the array principal[] gives the list of principals (possibly empty), which Y does not trust, and from such principals the propagation of authority is not acceptable to Y
C.5 Depth-First Search on graph G with constraints Z DFS(G, Z) for each vertex u ∈ V [G] do color[u] ← WHITE π[u] ← NIL for each vertex u ∈ V [G] do if color[u] = WHITE then DFS-VISIT(u) DFS-VISIT(u) color[u] ← GRAY do while u.K ! = Z.Array[i] . untrusted keys for each vertex v ∈ Ad j[u] do if color[v] = WHITE then π[v] ← u if v.delegation f lag ! = NULL && v.delegation f lag == 1 then d = d + 1 if d ≤ Z.delegation depth && v.Key == Sel f then return(π) DFS-VISIT(v) color[u] ← BLACK . backtrack now
24
