In an open network, how to provide deterrents to malicious behaviors is an important issue. A common technical solution is the use of cryptographic primitives such as encryption/decryption, digital signature, and digital signcryption. In this solution, execution logs are stored by each entity and used when needs arise for trouble settlement or judgement; authorities are involved mainly in the settlement phase. Depending on system-design and security policies, however, more active authorized procedures would be of great help. In preparation for such a situation, this abstract introduces an inspection mechanism for server-and-client protocols which are based on a private-key cipher.
In our society, authorized activities by police or similar organizations prevent or discourage people from committing a crime; potential criminals fear the consequences of their crimes which might be detected by the police. Inspection without notice, for instance, contributes to these activities. The mechanism described below is based on an idea similar to this inspection effect in the off-line world.
Let us consider a security protocol which uses a private-key cipher in important message delivery between a server (say, Alice) and a client (say, Bob). In order to use our inspection mechanism, the protocol must
- be designed in a way that the delivery request is always generated by Bob,
- provide two private keys per server-and-client pair, and
- have a secure channel (most probably established by very costly but highly secure protocols) between an authorized entity (say, Pole) and Bob.
In addition to normal procedures of the original protocol, we introduce inspection procedures in which Pole performs a behavior check on Alice.
In normal communication, Bob initiates the session by using one of the shared keys. Let us represent the chosen key by k1 and the other key by k2. Main process of the session, then, uses k1 for authentication, message delivery, and acknowledgement. Finally, Alice generates a new key k3, encrypts it with the non-session key k2, and sends the result to Bob. Bob decrypts the new key, and the shared keys are updated from (k1, k2) to (k2, k3); the next session will be initiated by using k2 or k3. k1 will never be used afterwards.
The inspection procedures start with a request message from Pole to Bob through a secure channel. If Bob accepts the request, he securely transfers one of the shared keys to Pole. Let us represent the chosen key by k1 and the other key by k2. Pole then masquerades as Bob; Pole initiates a session by using k1. Main process of the session delivers messages which are carefully designed for inspection activities by Pole. At the end of the session, Alice generates a new key k3, encrypts it with k2, and sends the result to Pole in disguise. Finally, Pole forwards the encrypted new key to Bob, and Bob decrypts it. Thus the shared keys are updated from (k1, k2) to (k2, k3), which are not disclosed to Pole. The next session will be initiated by using k2 or k3.
One of the possible applications of the proposed inspection mechanism is a storage support of digital valuables; not only cryptographic parameters but also digital personal materials such as artistic contents, family treasures, memorials, and digital certificates may require long-term secure storage in an electronic form in a future network life. Some of these storage requirements can be supported by Key-Recovery Systems (KRSs) , . KRSs are now actively discussed by the research community and a lot of different systems are being developed. Some of them and more general valuable-storage support systems — either for backup or for deposit — might use a client-server system equipped with a private-key cipher. How significantly our inspection mechanism works would depend on decision-making models and probably be a good subject for discussion at ETHICOMP98 Conference. More specific examples or implementations will appear in the final version of the paper.