Download the required Java packages as described here.
On UNIX, run the utility with:
java -cp /path/sdsi.jar:/path/cryptix32.jar
sdsi.control.SDSIMainFrame
On Windows, substitute ';' for ':' and '\' for '/'. Run from the command prompt, or use Start->Run.
In SDSI, a principal is a public key. Thus, the currently loaded identity is displayed as an abbreviation for that public key. Each public key is paired with a private key, so the currently loaded identity actually also has a private key loaded in memory. This private key is used to sign new certificates.
To load an identity, you must first have a public and private key pair. To create a new key pair, select "Key Pair!" from the "Create" menu. Key creation takes a few seconds, so be patient. You will be prompted for filenames for the public and private keys. You should choose these filenames so that they're easy to pair together, e.g. "alice.pub" for Alice's public key and "alice.prv" for Alice's private key. Here, "Alice" is an imaginary person who is the owner of this key pair.
Now that you have a key pair, you can load it as the current identity. Select the "Identity" tab and select the public and private key files of the identity you want to load. Finally, click "Load Identity". If all goes well, the new identity should appear in the Identity Bar.
Name certs are actually more general than this. Name certs can bind names to names defined by other principals. For example, Alice could bind "friends" to "Robert friends". This means that her group called "friends" also includes the group that Bob calls friends. Finally, name certs can be bound to arbitrary objects identified by their hash value.
To create a name cert, click on the "Certs" tab and the "Create Def" sub-tab. Type the name to define (e.g., "Robert") in the upper text field. In the lower area, select the subject of the cert. This may be another principal (a public key), a name, or an object hash. To select a subject, double-click on it in the object list. If you're binding a name to another name defined by the same principal (e.g., binding Alice's "friends" to Alice's "Robert"), you can change "Double-Click" to "Type a Name" and just type the new name in.
To create subjects like names defined by other principals and object hashes, use the "Name" and "Hash" tabs, respectively. A name is simply a principal and a sequence of strings separated by spaces. For example, set issuer to Alice's public key and set names to "Robert friends" to create the name "Alice's Robert's friends". The "Hash" tab lets you create the hash value of any SDSI object selected from the object list or a file on disk. To turn a hash into an "object-hash", select the hash and then select "Object Hash!" from the "Create" menu.
Certificates can also include a validity period: a time during which they are valid, outside of which they are not. A certificate with no validity period is always valid. To specify a validity period, enter a begin timestamp ("Not Before"), an end timestamp ("Not After"), or both. The format of the timestamp is YYYY-MM-DD_hh:mm:ss, where YYYY is the four-digit year, MM is the month (1 to 12), DD is the day, hh is the hour (0 to 23), mm is the minute (0 to 59), and ss is the second (0 to 59).
Auth certs are similar to name certs, except instead of naming a group of principals, they convey a permission or right to those principals (e.g., the right to read a particular file). The permissions are called "tags" and their format is defined in the SPKI/SDSI standard. In addition, auth certs support the ability to delegate a permission to the subject principals using the "propagate" flag. For example, Alice could create an auth cert with the tag "read", the subject "Robert", and the propagate flag set. Alice has also defined the name "Robert" to mean Bob, so this cert means that Alice allows Bob to read (e.g., one of her files). Bob could create an auth cert with the tag "read", the subject Carol's public key, and the propagate flag off. This allows Carol to read Alice's file, but Carol cannot delegate this right to anyone else.
Auth certs also support "threshold subjects", which let you delegate a permission to a joint set of principals. For example, Alice might allow someone to read her files if her parents, her friends, and her siblings all say that that person can read. To create such a subject, click on the "Threshold" tab and list the subjects that must be consulted. The "threshold" number says how many of these subjects must agree for the permission to be granted. For this example, the threshold is 3, since all three parties must agree. A threshold of 2 would mean any two of the three parties could grant the permission.
Certificates alone don't mean anything unless they're signed by their issuer. When you create a certificate, you are asked whether you'd like to sign it. If you say no, the certificate is invalid. However, you can choose to sign the certificate (or any other object) later by selecting the certificate and selecting "Sign" from the "Object" menu.
A SDSI certificate along with its signature makes a statement, such as "Alice says 'friends' includes Robert" or "Alice says 'Robert' means Bob". To keep certificate-signature pairs together, SDSI provides the "sequence" data struture. You can create sequences of certificates and signatures by selecting the "Sequence" tab and using the buttons to add and remove objects from a sequence.
Taken together, a sequence of certificate-signature pairs also makes a statement. For example, a sequence of the above two certificates (with their signatures) means "Alice says 'friends' includes Bob". Auth certs can be connected in a similar fashion: the sequence "Alice says Bob can read (with propagate)" + "Bob says Carol can read" means "Alice says Carol can read". In fact, auth certs and name certs can be mixed in the same sequence: "Alice says Robert can read (with propagate)" + "Alice says 'Robert' means Bob" + "Bob says Carol can read" means "Alice says Carol can read".
We call sequences that make statements "proofs", since they prove that a statement holds. Creating proofs can be hard for people to do manually. For this reason, the utility provides two automated ways to create proofs.
The first proof technique is called "closure". Closure essentially tries to create all proof sequences possible from the set of loaded certificates and signatures (acutally, it only creates those sequences derived from the "name-reduction" closure, as defined by Clarke et al). To run the closure algorithm, select "Closure!" from the "Create" menu . Closure creates new, unsigned certificates in the objects list (note that signed certificates start with a "*", while unsigned ones do not). To see the sequence of signed certificates that proves an unsigned one, select the unsigned certificate then select "Proof!" from the "Create" menu. This will add the proof sequence to your object list and select it.
The second proof technique is accessible from the "Prove" tab. This technique lets you to specify what you want to prove, much like how you might define a name or auth cert. For example, you might select Alice's public key as the issuing key, "Robert" as the name, and Bob's public key as the target subject. Click the "Prove" button to see whether the prover can find a proof. If it can, the proof sequence will be added to the object list and selected.
Finally, the utility can automatically verify whether a proof sequence actually proves an assertion (because it is possible that a prover might make a mistake). Verification is important for applications like access control. Suppose Alice only lets her "friends" read her files. Now suppose Mallory attempts to access Alice's files. Alice's access controller requires that Mallory present a proof that she is in Alice's group of "friends". Here, Mallory is the prover, and Alice's access controller is the verifier. Thus, Alice must trust her verifier, but she does not need to trust Mallory or Mallory's prover.
To verify a proof sequence, select the "Verify" tab. Specify the assertion to verify (as with the "Prove" tab) and select the sequence that you believe proves that assertion. Click the "Verify" button to check the proof against the assertion.