Signer access point

Three types of access points at the user interface are common to all signature schemes (see Section 5.1.2, Granularity of Entities ) signer access points, recipient access points, and court access points. 

The most common transaction is authentication. The events at the signer access point and the recipient access point that form such a transaction are now described in detail. They are summarized in Figiure 5.4, and some reasons for the decisions follow after the figure. (Remember that an example of what may happen under the interface was shown in Figure 5.1.)... 

Formal predicates. The first predicate models that the user with identity id tries to start initialization for the signer idg in the current round. It reflects that initializations for id cannot be attempted at signer access points other than idg. The parameters ids if and N are the set of possible recipients and the message bound that this user wants. 

In particular, if the signature schemes mentioned in the previous chapters are redefined in these terms, an entity below an access point of a signer generates the secret key for that signer, stores it, and performs all local administration, such as maintaining the above-mentioned counter for the messages authenticated so far (see Figure 5.1). 

At an access point of a signer, only one identity is handled. With simple signature schemes, this means that only one secret key is handled within the entity. 

An access point of a recipient or a court handles all the identities of signers. With simple signature schemes, this means that an entity of a recipient or a court handles all the public keys. This has the advantage that the administration of the relation between identities of signers and public keys is hidden inside the system. 

If related inputs at several access points are necessary, for instance the signer s command to sign and the recipient s command to test in Figure 5.1, they are assumed to occur in the same round. 

Disputes are between one recipient, one court, possibly one signer, and possibly all the centres. Thus all the access points of all new types may take part. The court s conclusion in a dispute may not only be that the message was or was not authenticated, but also that a certain subset of the centres is to blame. 

Secondly, from a purely theoretical point of view, consider what would happen if the identity was an input in such a service If the specification would really permit all identities at all access points, everybody could enter the identity of somebody else. Hence there would be no security in the intuitive sense of the real world. (This cannot be avoided by declaring something as the identity that someone else cannot enter, such as a password or biometric information The recipient and the court have to know an identity of the signer, and it is this very identity this paragraph deals with, because the requirements have to express facts like if a signer with a certain identity did not authenticate a message, no court should believe that the signer with this identity did .)... 

A possibility that would work is that the signer enters the identity, but that only one identity works at this access point (i.e., the entity inside checks the identity), but that would be redundant. 

For the case where a user can sign under several identities, one might have defined access points that handle a certain number of identities and where the currently used identity is an input (whereas in the definition above, such a user needs several access points — of course, they can be implemented on the same device). However, in practice, a signer would not want to input an identity, i.e., the string under which recipients and courts know her, but a local identifier such as sign for bank or sign for credit card . This corresponds to the way access points are selected in software. 

A dispute involves events at two or three access points a recipient access point, a court access point, and possibly the access point of the supposed signer. The supposed signer is defined as the one whose identity the court enters the adjective supposed is sometimes omitted in the following. The events described now are summarized in Figure 5.5, and some reasons for the decisions follow after the figure. 

Before the standard transactions can be performed, initialization must take place at the corresponding access points. Initialization at the interface represents key generation and key distribution within the system. Roughly, each user who takes part inputs a command init , and everybody obtains an output that denotes whether initialization was successful. The main parameters of the interface events are identities, in particular, that of the future signer however, several variants are conceivable as to which of the interface events have this parameter and whether more identities occur explicitly. 

One could have distinguished inputs init as signer , init as recipient , and init as court however, the same information is implicit in the types of the access points. 

However, in practice, the identity is present in the entity under an access point in the form of access to a broadcast channel under this previously known identity (for the time of initialization). For instance, with an ordinary digital signature scheme, the public key is broadcast on this channel inside the system during such an initialization. Similarly, if the system contained an authority that issues key certificates, the entity would need access to a secure channel to the authority under this identity, e.g., via the user who makes a handwritten signature. Note that the entities of all signers still use the same program e.g., they use a particular port for broadcast outputs. 

The signer inputs her command init at the special access point,... 

Local transactions, i.e., transactions involving only one access point, can be added quite easily to most schemes. For instance, a transaction where the signer asks how many messages can still be authenticated at a certain access point is useful. Recipients might also be interested to know with which signers they have already carried out initialization and what authenticated messages they have received. 

Although memory-less signing has been given some importance, e.g., in [Gold87, G0MR88], the only qualitative advantage I see is that it implies that the signer s access point can easily be duplicated (see Section 5.2.11, Local... 

Generalization. Both models presented above consider active attacks on all types of access points, i.e., not only on signers, but also on recipients and courts. 

The other reason is that, as mentioned in Section 5.2.9, a fiill fail-stop signature scheme is closely related to a scheme with special risk bearers where each user who acts as a signer, recipient, or court, also has a risk bearer s access point available. In fact, if a scheme is given where an arbitrary number of risk bearers can take part, one can constract a fiill fail-stop signature scheme as follows Each entity of the new scheme consists of two parts one part acts like a risk bearer s entity and the other like an entity of a signer, recipient, or court, respectively, from the underlying scheme. As risk bearers entities only take part in initialization, this only concerns the program parts for initialization (if those can be identified statically). The outer parts of all entities must handle the fact that the two parts share their ports. 

Outside the signature scheme The person who uses the signer s access point is given a risk bearer s access point (and entity), too. 

---