Moreover, the drive's long-term secure state is limited to a secret key hierarchy for each partition. Briefly, a file manager agreeing to a client's access request privately sends to the client a token and a key, which together form an object capability. Client requests on a NASD drive contain the capability token and are digested with the capability key. The drive, using the partition's secret key, constructs the implied capability key as a function of a request's capability token and verifies the request's digest. Agreement of delivered and computed digests ensures the drive that the capability token is authentic and the request's composer holds the corresponding capability key.
Revocation exploits the object version and rights expiration time fields of each capability token.
For example, immediate revocation is effected by directly modifying the object's version attribute on the drive. Implemented a prototype NASD drive exhibiting all features of our security protocol and most of the NASD object interface. Operating in the Digital UNIX 3.2g kernel of a DEC Alpha workstation, our prototype emulates a native NASD object store using a modified version of the local UNIX filesystem backed by an HP 2247 1GB disk. Encoding NASD drive and object naming in NFS' file handle and piggybacking capability acquisition on NFS pathname component lookup operations, modifications to NFS client code are simple and localized. Version 3.4 of the AFS distributed filesystem has also been adapted to use our NASD prototype.