Our protocol for using capabilities is similar to that of NASD [10,9] and SCARED [19], except that our capabilities describe access in terms of blocks rather than objects. Intuitively, a capability is a self-descriptive certificate that grants a specified type of access to parts of a disk (see Figure 1) when used with an associated secret. Our capabilities contain a group ID and a capability ID, which are used for revocations as explained in Section 2.2; a disk ID, which specifies the disk to which this capability applies; a list of extents, the ranges of physical blocks for which access is being granted; and an access mode (read, write, or both).
![]() |
The secret is used to prevent forgery of illegal capabilities or of
illegal requests using legal capabilities, as we now explain. The
secret is generated using a
keyed-hash message authentication code, or MAC
[1]. A MAC function
returns a string
of fixed length with the following
unforgeability property:
without knowing the value of
, it is infeasible to
find any new pairs of
and
such that
.
MAC functions can be computed quite efficiently in practice,
unlike public-key signatures.
Every capability is associated with a secret
, where
is a secret key shared by the metadata server and the disk whose ID
is specified in
. (There is a different key for each disk.) The use
of this secret is best explained by an example.
Figure 2 shows a client opening a file for the first
time, and then reading or writing some data. To open the file, the
client contacts the metadata server associated with the file. If the
file's metadata is not cached at the server, the server must retrieve it
from the relevant disk, shown by dashed lines in the figure (the
metadata server accesses the disk in the same way that the client does,
which we explain below).
The server checks if the client is permitted to access the file, and
if so it gives the client the following: (1) the list of physical blocks
comprising the file (its blockmap), (2) a capability for the
file's blocks2 with the requested access mode (read, write, or both), and (3) the
secret
associated with
. The server's reply (in
particular
) must be sent over a secure channel (shown by a
darker line in the figure) to prevent
eavesdroppers from learning the secret needed to use the capability. A
secure channel can be obtained by encrypting under a block cipher using
a session key established by an authentication protocol such as
Kerberos.
![]() |
Next, in order to read or write data from or to the file, the client
issues block requests to the disk using the capability that it obtained.
More precisely, the client sends to the disk an operation
that consists of (1) the type of access (read or write); (2) the range
of physical blocks to be accessed; and (3) in case of a write operation,
the data to be written. Together with
, the client also sends
the capability
provided by the server and a MAC
,
where
is the secret associated with
. Because
, we call this trick the ``double MAC''. (The double
MAC is not new; the earliest references we know of are Gobioff
et al. [10] and Mittra et al. [16].) The disk
can verify that the MAC is correct since it receives both
and
, and it has the secret key
. Note that the double MAC serves a
double purpose: (1) it is a proof that the client knows
and thus has
been authorized to use the capability
to issue the operation
, and (2) it prevents
from being tampered with, because
if an attacker changes
it would not know how to compute the
required new MAC.3
Once the disk has checked and executed the requested operation , it sends back a response
together with
. Here
contains data (if the request was a read)
or simply an acknowledgment (if the request was a write). The client
verifies that
was computed correctly, which prevents
responses from being forged.
For simplicity, we presented this example without encryption for
privacy. One simple way of adding encryption involves the server also
giving the client a session key and a token, which is
encrypted
under
; the client and disk encrypt their messages using
,
prepending the token in the clear so the disk can figure out which
session key to use.