Computer Staxhrds & Interfaces 17 (1995) 69-79

Non-repudiation: onstituting evidence and proof in digital coo~e~~t~

Siegfried Herda

En digital cooperation, mechanisms and scrviccs have IO bc prtGicd !O xcount for actions and ~~f~)r~i~~t~(~r~ to

cntitics. Digital signnturcs xc regarded as 3 means of establishing accountability. the prctpcrty that cnsuccs that the

actions elf an entity may he trnccd uniquely to that entity. IIowcvcr. to constitute proof of origin, submission, dclivcry

and rccuipt. digital signature tcchniqucs hnvc to bc suppcxtcd by certification, time stamping and n~)t~ir~~~lt~~n

tochniqucs nnrl scrviccs. The tcchniqucs providing proofs arc called non-repudiation tcchniqucs. Wrxking Group 2

rrf lSO/lES JTCl/SC27 (Security Tcchniqucs) is conccrncd with the standardization of security ~~~~b;~n~s~l~ and

algorithms such as digital signatures. A now work item has been dcfincd on nori-rcpu~li~ltion ~~~~IliL~~~~ using

asymmetric (digital signatures) ia well as symmetric cryptogr:tphic techniques.

KC)W/tdX: Son-rcpucli~rtion; Eviricncc; Accountability; Authentication: Integrity; Ccrtificaticln; Digital signatures;

I*roc)f of origin; Proof c)f rcccipt; f’roof of submission; Proof of dclivcry; Trusted Third Party; Timi: stamping

Bn the past, messages of some relevance were usually confirmed by a hand-written signature. As

more and more daily work is performed with support uf, or even completely by, computers the question of how to make a person accountable and liable for his actions and data had not been put on the table. Computers have been regarded as infaliiblc, and thus to sign computer printouts of rclevant mcssagcs was regarded unnecessary. But time has changed. Cases of computer fraud, from impersonation and pcnctration to d2magcs caused by computer viruses, have dcmonstratcd tha: computers ax susceptible to a wide variety of misuse. This has resulted in a dccrcase of

confidcncc in computers and computer supported

work. Even if some people have not yet reaiised

it, accountability and liability have become an important issue in computer supported cu-oper- ation and communication. What was needed was an equivalent to the hand-written signature.

‘The concept of digital signatures, d~v~~~p~d by Diffic and Hellman [I] in 1976 was a step towards a solution of the problem of finding an ~~~iv~l~~~t ‘digital’ substitute for the hand-written signature. The first practical solution was ~r~~~~~~d by Rivest et al. [7J known as the RSA ~ub~jc-k~y cryptosystcm that can bc used fur

70 S. Hrrdu / Computer Standards & Inttvjkes I i ( 1995) 69- 79

ment and signatures. Cryptosystems with a key pair, one key for each of the two related crypto- graphic transformations. are called asymmetric cryptosystems. The two transformations have the property that, given the private transformation, it is computationally infeasible to derive the public transformation. The prkafe key of an entity’s asymmetric key pair is only known by that entity and is called the entity’s signature key s, in the case of a signature scheme. It is called the entity’s decipherment key n in the case of an encipher- ment system. The public key of an entity’s asym- metric key pair is publicly known and called the entity’s verification key 13, in the case of a signa- ture scheme. It is called the entity’s encipherment key e in the case of an encipherment system.

1.2. Lbnitcrtions of digital signtrtiires

Digital signatures serve as an equivalent sub- stitute of hand-written signatures only if a couple of organisational and technical rcquircments are fulfilled. First, a strong link has to bc established technically hctwccn the signer and his asymmct- ric key pair. Scconcl, iI trusted third party has to approve that the asymmetric key pair belongs to that particular signer. To achicvc this, the ccrtifi- cation authority (CA) signs the entity’s vcrifica- tion key, distinguished name, the expiration date of the key. etc. with its signature key. By this an author of a signed message cannot repudiate that a particular mcssagc was from him but from someone else.

However, in many cases of business and pri- vatc lives, digital signatures illOflc are not suffi- cient to make the signer accountable for his ac- tions or his data. As in the conventional world, it depends on the legal environment and on the agrccmcnt bctwecn the partics involved in a par- ticular application whether signatures can serve as evidcncc in a trial. In the computer world, something ncods to be introduced which neither the signer nor the verifier of the signature are able to modify, and which depends on secret information supplied by a third party trusted by both. Additional cvidcntial information may be rcquircd such as time stamps, date of signing, a counter-signature provided by a notary, etc. By

that, information exchanged or stored for later use are rendered non-repudiable.

1.3. Evidence and proof

The goal of the non-repudiation service is to collect. maintain, make available and validate ir- refutable evidence. Evidence is information given to establish a fact or point in question (according to the Oxford English Dictionary). Evidence does not necessarily prove truth or existence of some- thing but contributes in establishing proof. Proof is evidence that serves to prove truth or existence of something (according to the Oxford English Dictionary).

Technically, evidence is generated with the secret or private key of the signer. With symmet- ric cryptographic techniques, the signer and the verifier must bc a third party trusted by both the evidcncc generator and the evidence user. This is due to the fact that there exists only one key which is used for both the generation and the verification. With asymmetric cryptographic tcch- niqucs two keys arc available, one - kept secret - for generating the signature, the second - made public - for verifying the signature by cvcryonc.

2. Non-repudiation

Non-repudiation involves the generation of ev- idence that can be used to prove that some kind of event or action has taken place so that this event or action cannot be repudiated later. Non- repudiation is not restricted to OS1 environ- ments, the service can apply to the generation, storage, and transmission of data.

A non-repudiation service (Fig. 1) may have several forms: - Non-repudiation with proof of origin is intended

to protect against a sender’s false denial of sending the message or its contents. This may be achieved when one entity, the scndcr of the data, delivers a proof of origin to another entity, the reccivcr.

- Non-repudiation with proof of receipt is in- tended to protect against a recipient’s false

S. Her& / Computer Standards & Interfaces 17 (1995) 69- 79 71

Originator

Pmol of nceipl

Recipient

Recehfer B

I

UA-0 Q (.,.,

I I Delivery Authority \ 1

Legend: - security Service

UA : User Agent MS : Message/ File Score TA : Transfer Agent

Fig. I. Non-repudiation services.

denial of having received the message or its contents.

- Non-repudiation with proof of arhrnission is in- tcndcd to protect against a dclivcry authority’s false denial of having the message acccptcd for transmission.

- N~~rr-reptrtlitrliorl with proof of delil-cry is in- tcndsd to protect against a delivery authority’s false denial of having the mcssagc delivered into the mcssagc store of the intcndcd rccipi- ent. There arc sonic additional non-repudiation

services not included in standards so far. If there is a real need for them, they will probably be included in standards in future - Non-reprtdiarion with proof of ownership is in-

tended to protect the author (creator or owner) of an information from the false claim of an- other entity of being the author (creator or owner).

- Non-repudiarion with proof of transfer counters the vulnerability of repudiation of responsibil- ity between transfer agents and/or manage- ment domains.

- Non-repudiation with proof of rerrie~al counters the vulnerability of repudiation of responsibil- ity of a message between a user agent and a transfer agent.

Evidence is information to be provided to an evidence user in a non-repudiation process gener- ated by the non-repudiation initiator or by a Trusted Third Party OTP) on behalf of the initia- tor. The initiator may be the originator, recipient, or the delivery authority. Non-repudiation evi- dence consists of a non-repudiation token either sealed with a secret key known only to a TTP, or of a Digital Signature with a public-key certificate issued by a ITP acting as a Certification Author- ity (CA).

2.1. Phases of non-repudiation

The process of non-repudiation occurs in four distinct phases: - evidence generation, - evidence transfer, storage and retrieval, - evidence verification, and - dispute resolution, or arbitration.

In the evidence gemration phase, cvidencc is gencratcd by an evidence generator after the initiation of a process. Evidence is gcncratcd cithsr by the initiator itself or by a trusted third party on behalf of the initiator.

During t hc el*ide~e tramfer, storage and rc- rriel,al pl~se, evidence is transferred bctwccn par- tics, c.g. the evidcncc gcncrator and cvidcncc user, or to or from storage.

In the f:erifkaGon phase, evidcncc is vcrificd by an cvidcnce verifier at the request of an evi- dence user. An evidcncc user may request verifi- cation in order to bc confident that the evidencr supplied will be adequate in case a dispute arises.

In the dispute resolution phase, an adjudicator resolves disputes between parties. The adjudica- tor collects information and evidence from the disputing parties. An adjudicator may also re- quest evidence from a notary or from an evidence recording authority. To convince itself of the cor- rcctnrss of the evidence, the adjudicator will rc- quest verification from a verification authority.

2.2. Non-repudiation policies

Non-repudiation policies are determined by three factors: the legal environment, the specific application, and the anticipated threats. The

77 - S. Her&t /Computer Standards & Interfaces 17 ( 1995) 69-79

threats may sometimes be induced by the particu- lar application or its implementation. Non-re- pudiation policies specify rules to be applied for the generation and verification of evidence as well as for adjudication. They may be expressed as rules imposed on the parties. or as an agree- ment behveen the parties. For example, in Elec- tronic Data Interchange for Finance, Administra- tion. Commerce, and Transport (EDIFACT) ap- plications the communicating parties exchange

policy messages before any EDIFACT message exchange.

3. Trusted third parties

3.1. Reasons for inr-oll*ement

A trusted third party (TTP) is involved for three reasons:

’ : I ’ I I I ’ ’ i I

' : I

' : I

' I I

' : I

' I !? ' 2:' '-

A!?' 'S 0' 'E

I 1% I I-u

I '4

' I I

' I I

' ! I I '

' : I

' I I

' : I I '

SeWiCe : ’ I Response Request 4 ’

Evidence /?ecord Keeping

,------------ Intermediary

Fi

I------------

Evldence 0 Recording Authority

-----------

‘vi ‘vi -----------------------

Signatures

pgii-j p!Jgi-1

SeNice ?,I’ Trusted Third Partie VW

Proof of Origin Token Originator A c Recipient B Proof of Receipt Token -

Fig. 2. Basic structure of non-repudiation.

S. Hrrdu /Computer Standards & Interfuces 17 (1995) 69-79 73

- The non-repudiation policy in effect for a par- ticular application requires the evidence to be generated partly or totally by a TTP.

- Symmetric cryptographic techniques used for generating Signatures/Tokens always require the evidence to be generated by an on-line or in-line TTP where the secret key is known only to that TTP.

- The adjudicator accepts only evidence that is confirmed by one or more TTPs.

As a monitor. the TTP does not intervene directly in a non-repudiation exchange but monitors the action or event, and is trusted to provide evidence about what was monitored. As an intermediary. the TTP intervenes di- rectly in a non-repudiation exchange. The in- termediary generates the evidence (proof of origin and receipt) and performs the exchanges between the initiator and the evidence user.

3.2. Way of inl*ohument of trusted third parties 3.3. The role of Trusted Third Parties

Trusted Third Parties may be involved in dif- ferent ways to provide evidence: - An off-line TTP supports the non-repudiation

process without being involved in each in- stance. An off-line TT’P can generate and dis- tribute off-line certificates which the evidence user can later use to verify the evidence. Ex- amples of off-line TTPs arc certification au- thorities which issue off-line key certificates for asymmetric key pairs, or key gcncration authorities issuing sccrct symmetric keys to bc used and only known by (another) TTP to gcncratc cvidcncc.

A TTP has basically three functions: - authentication - to verify the identity of an

entity, - certification - to certify the time and date, and - record keeping - to maintain a repertoire, to

store copies of valuable information (c.g. evi- dence), and to issue copies upon rcqucsts of lcgitimatc entities. One or more trusted third partics may he

- An on-lint IV is actively involved in every instance of the non-repudiation cxchangc. The on-lint TIP can bc requcstcd to gsncratc evi- dcncc (non-repudiation tokens) and may assist the evidence user to verify the evidence. The interaction of a sin& ‘ITP with the non-rc- pudiation initiator or evidence user can bc extended to a chain of TTPs communicating directly or indirectly with the initiator or cvi- dence user, for example to provide or validate a trusted time stamp. A Delivery Authority is an on-line TTP acting as an intermediary that is trusted by the origi- nator and recipient to exchange the data to- gethcr with the proof of origin or proof of receipt respectively. The delivery authority provides proof of submission and proof of dc- iivcry for the initiating party (originator or rccipicnt) either by gcncrating the cvidcncc itself or by another TTP (see Fig. 2).

involved in a non-repudiation process, and they may act in various roles, e.g. Signaturc/Tokcn gcncration and verification. ccrtificatc gcncra- tion, time stamping, notarisation illld cvidcncc record keeping. A single TTP may act as one or more of thcsc authorities dcpcnding on the appli- cation. Functions of the TTP may include a role in the evidence generation phase. in the evidence transfer and recording phase, and in the evidence verification phase. The roles can be grouped ac- cording to these phases as follows:

Evidence getwrution In this role, a TPP co-operates with an origina-

tor, rccipicnt, or delivery authority to gcneratc cvidcncc.

In the Signuture generation rok, the TTP acts as an on-line authority which is trusted in the same way by the entity responsible to provide evidence, or by the adjudicator to provide cvi- dcnce on its behalf.

- An in-line TTP may act as a monitoring au- thority or as an intcrmcdiary.

In the Token generation role, the TTP acts as an on-line or in-line authority which provides non-repudiation tokens related to the non-rc- pudiation initiator.

74 S. Her& /Computer Standards & interfaces I7 (1995) 69-79

In the Cerrificurion role, the TTP acts as an off-line authority which provides off-line certifi- cates related to a non-repudiation initiator in order to assure the genuineness of the public key to be used for non-repudiation purposes.

In the Time stamping role, the ITP provides evidence which includes the time of the event such as creation time of a document. or evidence generation time.

In the Norarisation role. the TTP. trusted by the communicating entities and fourth parties, provides assurance about the property of the data communicated between two or more entities. such as the data’s integrity, origin, destination and time/date. The assurance may be established by a countersignature of a document that may be already signed by the non-repudiation initiator.

ItI tcrttwdiar) In this role. a ITP is responsible for the cx-

change of non-repudiation messages. In t hc In-he ecidencc getwution and transfl*r

t-c)L, the intermediary gcneratcs the evidcncc (proof of origin and receipt) and performs the non-repudiation exchange.

In the Ott-he deficwy role, the ‘IT1 performs the non-repudiation exchange and provides proof of submission and proof of dclivcry for the initiat- ing party (originator and/or rccipicnt) cithcr by gcncrating the evidence itsslf or by another TTP.

In the kkidettce record keepitlg rok, a TTP records evidence that can be retrieved later by an cvidcncc user, particularly by an adjudicator.

El ~idetice i wificu rior i In the signature verification role, the TTP acts

as an on-line authority which is trusted by the evidence user to verify evidence.

4. Standardization of non-repudiation services

In the ISO-OS1 Basic Refercncc Model-Part 2: Security Architecture [2], non-repudiation is dcfincd as a security service which may take one of the two forms: non-repudiation with proof of origin, and non-repudiation with proof of dcliv- ery. In the meantime, new applications such as

Message Handling Systems (MHS). or Electronic Data Interchange for Finance, Administration, Commerce. and Transport (EDIFACT) have been developed which require additional non-repudia- tion services such as the delivery service provid- ing proof of submission and proof of delivery. However, the meaning of deficery is different from the definition given in [2]. What is denoted by non-repudiation with proof of delivery in [2] is called non-repudiation with proof of receipt.

4.1. Non-repudiatiotr framertpork

ISO/IEC JTCI/SC21 in collaboration with ITIJ-TS (formerly CCIIT) is jointly developing multi-part Standards on Security Frameworks for Open Systems where ‘Open Systems’ is not con- fined to the OSI environment, but includes Databases. Distributed Applications and Open Distributed Processing as well. The scope of the frameworks is described as follows [3]: “The Sc- curity Frameworks arc concerned with defining the means of providing protection for systems and objects within systems, and with the interac- tion bctwccn systems”. The scope of the Non-rc- pudiation Framework in particular is described in [31: (I 1 defines the basic concepts of non-rcpudia-

tion; (2) defines general non-repudiation services; (3) identifies possible mechanisms to provide the

non-repudiation services; and

for non-repudiation services and mechanisms. The Non-repudiation Framework clearly states

(4) identifies general management requirements

what is outside its scope and what should bc developed in the standards on mechanisms: “This Standard.. . does not include specifications of de- tails of the protocol exchange which need to be pcrformcd in order to achieve non-repudiation” and “ . . . does not describe in detail the particular mechanisms that can be used to support the Non-repudiation service.. . “. These two points will be covered by a multi-part standard on non- repudiation mechanisms currently being devel- opcd by ISO/IEC JTCl/SC27 Security Tech- niqucs.

S. Hrrdu /Computer Studurds & Inrerfuces I? f IYVi) OY- 7Y 75

4.2. Non-repudiation mechaniks: Part 1: General into effect for a particular application, further

model trusted third parties may be involved.

This first part of the multi-part standard on non-repudiation [41, being developed by SC27/ WG:! as the General Model. specifies what the subsequent parts have in common with respect to definitions and notations. general requirements.

the definition of the non-repudiation services to be covered, the way trusted third parties are involved and their roles. and the abstract specifi- cation of Signatures based on symmetric and asymmetric cryptographic techniques. The defini- tion of Tokens used to convey evidence in each

non-repudiation service leads to the definition of a generic Token as a Security Information Object (SIO). The standardization of SlOs is a work item of SC27/WG 1 ‘Requirements, Security Services and Guidelines’. There is some overlap between the Non-repudiation Frnmcwork and this Gen-

eral Model.

5. Signatures as basic elements for the generation of evidence

Evidence is generated by signing non-repudia-

tion information (NRI) using symmetric or asym- metric techniques. The term Signature (SIG) is introduced as a generic term for Secure En- velopes (SENV) based on symmetric crypto- graphic algorithms and for Digital Signatures (S)

based on asymmetric cryptographic algorithms. For each kind of non-repudiation a Token is composed from the signature SIG concatenated with another data field text that may contain additional information relevant for the transac- tion or signnturc.

This part of the standard [S] specifies a method

of using symmetric enciphcrmcnt algorithms as a mechanism to provide a non-repudiation scrvicc which supports proof of origin and proof of rc- ccipt. Due to using symmetric cryptographic tcch- niqucs, this standard relics on the cxistcncc of a trusted third party to generate the evidence in

every instance of the non-rspudiution process. This part basically covers non-repudiation mccha- nisms with an on-lint ‘ITP. Non-repudiation with proof of submission and with proof of dclivcry is not explicitly covcrcd so far.

For a SENV to bccomc a part of an irrcfutablc cvidcncc, it can only be gcncratcd by a Tl’l’ using

a key known only to the ‘ITP itself. A SENV may also be used for the authentic and/or confidcn- tial communication bctwccn the entity rcqucsting a non-repudiation service and the ‘I’l’t’. In this GISC the SENV is generated with a key known by

both parties.

SEN V genmrtcd by enciphermctl t The SENV is gencratcd by enciphering the

NRI with the secret key x. The NRI consists of a message y concatenated with some redundancy RED dcrivcd from y without using a secret pa- ramcter:

4.4 Non-repudiutiorl mcchunisms, Purr 3: Non-re- pudirrtion using asymmetric techniques

The mechanisms described in this part of the

standard [6] achieve non-repudiation by the USC of asymmetric cryptographic techniques, such as digital signature mechanisms. Non-repudiation mechanisms using digital signatures as the basic mechanism need only an off-lint trusted third party as a public-key certification authority. Dc- pending on the non-repudiation policy brought

SlG,( NRI) = SENV,(y) = eK,(y II RED)

(e.g. RED may be a Manipulation Detection Code (MDC), or a Hash-code (HI).

SENV generuted with keyed redtrrukmcy The SENV is formed of the message y con-

catenated with a redundancy RED derived from y using a secret key x:

SlG,( NRI) = SENVJy) = y II RED,(y)

76 S. Herdu / Computer Standards & Interfaces I7 f I995) 69- 79

(e.g. RED may be a Message Authentication Code. MAC).

5.2. Digituitul signaturtcs

A Digital Signature S is generated by applying a digital signature algorithm S to the message J using the private key s known only to the signer:

SIG,(y) = sS(y) Digital Signature of data y ob- tained by applying digital signature al- gorithm S and private key s.

6. Tokens used in non-repudiation mechanisms

A Token is a data field associated with the message m to be transmitted from entity A to entity B and used to convey evidence. A Token consists of two parts. a data field z that is ren- dered unforgeable by the issuer’s Signature, and a data field &XI which may optionally contain a key identifier and/or a message identifier. The data field 2 consists of a flag p indicating the type of non-repudiation. the distinguishing identi- fier of the initiator A of the non-repudiation

ime/ date stamping

evidence recordin

time/ dale stamping,

PO0 = text1 II SENV,(zt) (proof of origin) PO0 = text1 II sS(zr)

POR = text2 II SENVx(z2) (proof of receipt) POR = text2 II sS(z2)

POS = texts II SENV,(z$ (proof of submission) POS = text3 II US

POD = texh II SENVx(z4) (proof of delivery) POD = text4 II sS(z4)

Fig. 3. Ovcrvicw of how IO provide evidcncc in non-repudiation services.

S. Her& / Computer Stunclardc & Interfaces I 7 ( 1995) 69- 79 77

exchange, the distinguishing identifier of the evi- dence receiver B, a time reference T. and the data field H(m) which is either the hash-code of the message m to be transmitted or the message itself. The time-reference T is either provided by the Signature generation entity (A, B, lTP) or by a time stamping TTP issuing and certifying time and date stamps. The Signature SIG is generated either by the initiator of the non-repudiation exchange or by a Signature generation TPP at the request of the initiator.

In the following paragraphs only proof of ori- gin and proof of receipt tokens are defined as examples. The proof of submission token and the proof of delivery token are similar. The data elements in the Token may be regarded as a minimum set, further elements may be added optionally. The time reference T is enclosed here in the minimum set, however. there are strong opinions to have it optional.

6. I. Proof of orisqin token (1’00)

The proof of origin token (PO01 is gcncratcd by the originator or by a TPP at the rcqucst of the originator:

PO0 = text, IISIG(z,)

zl = f, IIA IIBIIT, Ilki The non-repudiation information z, necessary

for a PO0 token may consist of the following minimum set of data elements:

f , flag indicating the signature is a proof of origin,

A distinguishing identifier of the originator, B distinguishing identifier of the recipient,

T, date and time the data was sent, H(m) hash-code of the data sent or the data

itself.

6.2. Proof of receipt token (POR)

The proof of receipt token (POR) is gcncratcd by the recipient or by a TPP at the request of the recipient:

POR = tcxt2 IISIG(z2)

=~=f~IInIIsnT~IIM(m)

The non-repudiation information zz necessary for a POR token may consist of the following minimum set of data elements:

f 2 flag indicating the signature is a proof of receipt,

A distinguishing identifier of the recipient. B distinguishing identifier of the originator.

T2 date and time the data was sent, H(m) hash-code of the data sent or the data

itself. Fig. 3 summarises the elements necessary for

the provision of evidence defined so far in the ongoing standardization of non-repudiation me- chanisms by ISO/JEC JTCl/SC27 Sacurity Techniques, WG2 ‘Security Techniques and Mechanisms’.

7. Non-repudiation nwchanims

In the non-repudiation standard [J-6], mccha- nisms arc defined for all types of non-repudiation provided by Signatures based on symmetric and asymmetric cryptographic tcchniqucs. The txam- plc given in Fig. 4 covers non-repudiation with proof of origin and with proof of rcccipt. In cast

symmetric techniques arc used, an on-lint TTP as the Signature (SIG) and PO0 and POR Token gcncrating authority is involved. In case of asym- metric tcchniqucs, it is assumed that off-line pub- lic-key certificates are available.

The communication between the entities A and B with the TTP has to be authentic and confidential. This may be achieved by using Sc-

Trusted Third Party l-fP

Fig. 4. Non-repudiation with proof of origin and proof of

receipt using an on-line IIT.

75 S. Herda /Computer Standards & Interfaces I7 II 9951 6% 79

cure Envelopes (SENV) generated with a secret key a known only by the ?TP and A, and key b known only by the TTP and B.

Notation SENV,: Secure Envelope generated with secret

key x known only to the TTP. ss: Digital signature S generated with the

(private) signature key s known only to the entity indicated in the subscript.

pon: ‘Positive or negative’. The result of the verification of the signature.

Note : The SENVs in italics indicate a possible implementation of a confidential and authentic transmission.

8. Open problems

There are still some problems which are not explicitly addressed: (1)

(2)

Thcrc is a disagreement whether there are dcgrces of trust with respect to the cntitics involved in the non-repudiation process. Thcsc different dcgrces may be due to the basic mechanism (evidence gcncration and verification) applied and the type of non-rc- pudiation service or secondary scrviccs addi- tionally used, such as time stamping sctvicc. A hierarchy of trust could be helpful in the development of guidelines on the USC and managrmcnt of non-repudiation scrviccs. The problem of a time reference is not yet satisfactorily solved. It is, however, not the

primary task of the standards on non-repudi- ation to solve this problem, but to point to solutions. There are only a few research re- sults, see e.g. [Sl.

(3) The revocation of public-key certificates is still an unsolved problem that needs to be solved, otherwise the advantages of asymmet- ric techniques over symmetric techniques would be reduced.

9. Conclusion

Non-repudiation mechanisms exist already in the paper world. For applications in computer communications, computer-based co-operation, and in the computer supported work flow appro- priate non-repudiation services and mechanisms have to bc dcvelopcd and standardized. Non-rc- pudiation is not only a technical issue, it is equally related to legal aspects. That is one reason why the definition of non-repudiation mechanisms is a difficult task. The goal must bc to dcfinc non-rc- pudiation mechanisms as gcncral as possible SO

that a large variety of non-repudiation politics arc met.

The GMD, a government funded research cen- tcr, has an obligation to consider socio-technical as well as legal-technical aspects. Therefore, non-repudiation must bc particularly considered, especially in those research groups which arc implcmcnting digital signature techniques in a wide variety of applications.

1 Part 2: using symmeffic I Part 3: using asymmefric I cryptographi% t&hniques PO0 = text1 II .SENVx(z,)

1 cryptographic techniques 1 PO0 = text1 11 S&(2,)

I Se0 I 1 POR = text> II SENVx(z,) I POA = text7 II SRS(Z,) I I (1; A

_.. -. - -.-. a TTP : SENV.(zl)

(2) TTP = A : sENv‘qpoo) (3) A a B : mllztllPO0 m II PO0

( ,(:I

t3 a TTP : SENVb(PO0 II z2) lTP a B : SENVhon II PO0 II POW

(6) B a A : RM -.

(7) A a TTP : SEtjV-lDMi\ ..a,. .#I ‘,

I I

1

(8) TTP 3 A : SEA JV,(pon II PO0 II POR) 1

Fig. 5. Protocol stcpc for exchanging PO0 and POR tokens gcneratcd by symmetric and asymmetric cryptographic techniques.

S. Hrrdu / Compufrr Srunciurds & Interfaces I7 (1995) 69-79 iv

References [g] St. Haber and W.S. Stornetts: How to time-stamp ;I digital

[II

El

(31

[Jl

El

[hl

[71

document in .&fcances in C~prolo~q - Proc. CRYPT0 90.

W. Diffie and M.E. Hellman. New directions in cryptogra-

phy. IEEE Truns. fnformar. Theop (6) (1976) a-1-654. IS0 7498.2: 1989, Information processing systems - Open

Systems interconnection - Busic Reference Model - Part

2: Security Architecture.

ISO/IEC DIS IOISl-4: Draft International Standxd.

Non-repudiation Framework. Dec. 1993.

ISO/IEC JTCI/WG2 N2.59 5th WD Non-repudiation.

Part I: General Model. Feb. 1994.

ISO/IEC JTCl/WCZ N230 5th WD Non-repudiation.

Part 2: Non-repudiation using Symmetric Encipherment

Algorithms. Sep. 1993.

ISO/IEC JTCI/WG;I N2-l WD Non-repudiation. Part 3:

Non-repudiation Mechanisms Using Asymmetric Tech-

niques. July 1993.

R.L. Rivest. A. Shamir and L. Adleman. A method for

obtaintng digital signatures and public-key cryptosystems,

Lvcrure lVores in Compufrr Science 537 (Springer-Verlag,

1991) 437-455.

After graduating from the University of Bonn. Siegfried Herda joined the GMD where he hns been involved in national and international projects in computer security. such as Open

’ Shops for Information Services. Trustworthy Telematic Transactions (both EC funded). Manipulation Se- curity of Software. and Legal and Technical Implications of Digital Sig- natures (German Government fun- ded). He is involved in Standardisa- tion on the national and international

level since 1983. He is one of the German delegates in ISO/IEC JTCl/WG? and is project editor for Non-repudia- tion, Part 1: General Model, and for Hash-functions, P;irt 4:

comm. ACM (2) (197s) I ?(I- IX Hnsh functions using modular arithmetic.