This section describes how access control systems can benefit from TTM. Tokens stored in TTM can be used as access tokens for accessing systems or objects. Gaining access to a system may require one to have particular tokens, whereas access to objects may require the ability to use wrapped keys. Table 5.4.1 summarizes different types of access policies that can be implemented with TTM. In a system supporting Type 3, for instance, access is granted up to n times for agents having certain B-T tokens. In the following, examples of systems supporting these access policies are discussed.
5.4.1
Online Access Control.
Consider a system consisting of a number users, an admin AD and an access control server AS. An user U needs to prove his credentials to AS in order to gain access to the system’s resources. Suppose that users are equipped with TTMs. AD initializes new tokens whose types are ttype, and distributes them to existing users. Assume for simplicity that B-T tokens are used. The admin can implement two interesting policies detailed as below.
1. AS grants access only to users that have the tokens, and for unlimited number of times (Type 4 access). The protocol is as follows:
(a) AS sends a nonce to U.
(b) U opens a transport session with its TTM, in which TTM ReadState(ttype) is executed. When the session is released, its log containing a token state tks is signed by the TTM using the nonce given by AS.
It verifies the signature and checks that tks.ttype ttype and tks.isRT F.
It grants U access to the resources only if tks.count¡0.
2. AD grants limited access, namely n times per user, to users who have the tokens (Type 3 in Table 5.4.1). In this scenario, AD gives n tokens to every user. The protocol is similar to that of Policy 1, except in the final step, before granting the access, AS asks U to transfer one token to it. U will not be able to gain access to the system’s resources once it has run out of the tokens. Users could lend their tokens to each other, but the maximum number of access granted to all users is nu (u is the number of users).
In these policies, the users can send their tokens back to AD at anytime and consequently give up their abilities to access the system’s resources.
5.4.2
Offline Access Control.
Consider a party DP that wishes to implement an access policy to its objects. The objects considered in this case are signing or decryption keys. The delegated key can be used by an user U only if U has certain R-T tokens. This scenario resembles a Digital Right Management (DRM) system consisting of a party DP that distributes encrypted objects to users. U needs to have specific tokens (given by to it by a separate payment system, for example) in order to decrypt the objects. A typical use-case scenario for such the system is as follows:
• The payment system gives U a range of tokens.
• DP ask U to create a wrapped key whose unwrapping condition are linked with the tokens that U just received.
• DP encrypts the data with a symmetric key sK which is in turned encrypted by the public part of the wrapped key given by U. The encrypted data and key are sent back to U.
• U is only able to decrypt the data if it can load and use the wrapped key to decrypt the encryption key.
DP can implements the following two policies. 1. For unlimited usage (Type 2):
(a) DP asks U to prove its possession of a range rx, ysttype. The proof can be
generated by U returning its TTM’s signature on the token state tks where tks.ttypettypeand tks.isRT T. U also returns the Merkle leaf containing
rx, ysttype and the verification path. DP then computes the root of the Merkle
tree and checks that it is the same as tks.root.
(b) DP asks U to create a wrapped key inside a transport session. The wrapped key wK is returned together with the proof (the session log and signature on the log from U’s TTM) that the key was created properly. In particular, the unwrapping condition is set to be:
pttype, cid, h,|rx, ysttype|, x, y,0q
(c) After verifying that wK was generated correctly, the public part of wK can be certified (when wK is used as a signing key) or used to encrypt data (when wK is used as a decryption key) by DP
To use wK for signing or decrypting, U must load it into the device using TTM LoadRKey command. Because the unwrapping condition specifies disc0, U can use wK the
key for as long as it has the rangerx, ysttype.
2. For n-time usage (Type 1):
(a) DP asks U to prove its possession of a range consisting of at least pn 2q
tokens whose types are ttype. U returns the proof for a range rx, ysttype where
|rx, ysttype|n 2. The protocol for this is similar to the one for the unlimited
(b) U transfers the range ry, ysttype to DP .
(c) Similar to the unlimited usage case, U creates a wrapped key wK inside a trans- port session and sends it back to DP . The main data fields of the unwrapping condition are set as follows:
i. cond.ttypettype
ii. cond.count1
iii. cond.rangepx, xq
iv. cond.disc1
To sign or decrypt with wK, U needs to load it into TTM using TTM LoadRKey command. disc tokens are removed from the range each time the key is used. Notice that step b is necessary, for it ensures that U cannot merge ranges together in order to use wK for more than n times.
The policies above could be implemented with B-T tokens (instead of R-T). However, U may need to maintain different types of tokens for different wrapped keys. Because the number of states in TTM is limited, such an implementation would not scale well. Using R-T tokens, up to 2160 ranges can be maintained in one state. Therefore R-T tokens allow
many wrapped keys to be linked with different non-overlapping ranges maintained by the same state.