WO2001071971A1

WO2001071971A1 - Digital contract

Info

Publication number: WO2001071971A1
Application number: PCT/FI2000/000231
Authority: WO
Inventors: Jarmo Miettinen; Jukka Liukkonen; Mikko MÄTTÖ; Henna PIETILÄINEN; Veera Lehtonen
Original assignee: Smarttrust Systems Oy
Priority date: 2000-03-21
Filing date: 2000-03-21
Publication date: 2001-09-27
Also published as: EP1266482A1; AU2000235603A1

Abstract

The invention relates to a method for making and transmitting a digital contract and to a method for receiving a digital contract over a telecommunication network between two parties, said telecommunication network and/or parties comprising at least a transport part and an application part, in which method the contract comprises at least the contracting parties, an object of agreement, a contract overlay to be used and contract data and in which method the contract is approved with a digital signature. In the methods of the invention, the information transmitted between the application part and the transport part comprises only the receiver or sender data, the contract data and the object of agreement. In the methods, only the most essential part of the contract is transmitted between the sender and the receiver, yet without compromising in any way on data security or legitimacy of the contract.

Description

DIGITAL CONTRACT

FIELD OF THE INVENTION

The present invention relates to telecommunication systems. In particular, the invention concerns a method for delivering information associated with a digital contract over a telecommunication network between two parties.

BACKGROUND OF THE INVENTION For the conclusion of an agreement between two parties, it is necessary that the parties have unanimous ideas regarding the matters to be agreed about. People make various agreements e.g. with banks or other business enterprises to receive and use their services. The basis for the conclusion of an agreement is that both contracting parties accept the contract data and the conditions associated with the contract.

Agreements can also be concluded via electronic data transmission without personal contact be- tween the contracting parties.

It is possible to make an agreement digitally in such manner that the sender and the receiver enter into a contract which is then confirmed with a digital signature. One method for digital signature is one in which both a public key and a secret signing key have been defined for the sender and the receiver. In digital signature, the sender generates a hash from the message and signs the hash with his own secret signing key. The receiver of the signed message decrypts the message using the sender's public signing key. The receiver can verify the origin of the message by comparing a hash computed by himself from the received message with the hash included in the message. If the hashes match, then the sender of the message is the person he claims to be. If necessary, the signed contract can also be encrypted to achieve privacy. The encryption is implemented using e.g. the public key method. In the public key method, both the sender and the receiver have both a public key and a secret key. When a message is to be encrypted, the sender encrypts it using the receiver's public key. The receiver decrypts the message using his own secret key, which is only known to himself.

A problem at present is that a large amount of data has to be transmitted between the parties entering into a contract. This constitutes a special problem for implementations and equipment having a limited data transmission and processing capacity available. A further problem is that the information transmitted between the contracting parties comprises the entire contract.

Another problem is the possibility of copying of the same contract. In other words, how to make sure that the signatory only confirms a single copy of each contract. One solution to this is centralized contract management .

The signature and possible encryption of an agreement has traditionally been implemented in the application part. Application part means e.g. the ap- plication layer of different protocol models. As a consequence, the application part becomes complicated and, moreover, the amount of information transmitted in the application part is large. In addition, the application part is often less safe in respect of data security than the transport part.

OBJECT OF THE INVENTION

The object of the present invention is to eliminate the drawbacks referred to above or at least to significantly alleviate them. A specific object of the invention is to disclose a new type of method in which the amount of data transmitted in conjunction with a contract is small and which still provides a high level of data security. A further object of the invention is to give the contract a form that allows it to be interpreted by a third party (such as a no- tary service) . Thanks to the invention, the application level can be implemented in an effective manner as it does not have to take care of any functions related to security of data transmission.

BRIEF DESCRIPTION OF THE INVENTION

The present invention concerns the conclusion of an agreement by a digital technique. In the method of the invention, a contract is encoded, signed digitally, decoded and verified and its legal competence is confirmed, and preferably the most essential part of the contract or the entire contract is transmitted between the contracting parties.

The invention concerns a method for concluding a digital agreement and transmitting it over a telecommunication network between two parties, said telecommunication network and/or parties comprising at least a transport part and an application part, in which method the agreement comprises at least the contracting parties, the object of agreement, a contract overlay and contract data, and in which method the contract is approved via digital signature. 'Transport part ' preferably refers to the transport layer represented by different protocol models, and 'application part' correspondingly refers to the application layer. The transport part may also be considered as consisting of a combination of several different protocol layers .

In the method of the invention, the receiver data, the contract data and the object of agreement in the application part are transferred from the application part to the transport part. Further, a header section including the receiver data, sender data and object of agreement is generated. The receiver data and the object of agreement are obtained from the application part. The sender data is stored in the transport part or is otherwise available to the trans- port part, from where it can be obtained and included in the header section. 'Receiver data' and 'sender data' preferably refer to a kind of network identity (NID) , comprising encryption and/or signing keys which have been linked to it in conjunction with its genera- tion. From the transport part, a connection can be established to a trusted third party (TTP) , from which the public keys associated with different network identities can be requested. 'Connection' may refer both to a connection oriented connection and a connec- tionless connection.

Based on the header section, the contract overlay is retrieved. The contract overlay is stored in the transport part or is otherwise available to the transport part. In what was said above, it is assumed that both the sender and the receiver are already in possession of the contract overlay to be used in conjunction with the agreement. The contracting parties agree beforehand about a contract protocol, which defines the contract overlay to be used and the object of agreement. 'Object of agreement' refers e.g. to an identifier indicating a given application which processes the information relating to the contract.

The contract overlay is completed by filling in at least the sender data, receiver data, contract data, object of agreement and a message counter associated with the contract. The contract data comprises more detailed information about the content of the contract. By using the data filled in, a hashed data section is generated. 'Hashed' means that the length of the hashed part is shorter than the sum of the lengths of the individual parts from which it was generated. The hash is generated using e.g. a method ac- cording to PKCS#1 version 2.1 (PKCS, Public-Key Cryptography Standards) or IEEE P1363 (IEEE, Institute of Electrical and Electronic Engineers) . This means encoding the actual cryptographic message, and the meth- ods listed above are examples of methods applicable. The cryptographic message implements the requirements imposed by the cryptographic algorithm on the message to be signed.

The sections generated - the header section and the data section - are combined for transmission as a contract message. The contract message thus produced is signed digitally by using e.g. the public key method. The signed contract message can additionally be encrypted, likewise using e.g. the public key method. The secret signing key needed for the signature is preferably stored in the transport part. The signed and possibly encrypted contract message is transmitted to the receiver, preferably in the transport part. The contract message is preferably trans- mitted in a short message in a mobile communication network. If the contract message generated is too large to be transmitted in a single short message, then it can be divided into several short messages e.g. according to the ETSI (ETSI, European Telecom- munication Standardization Institute) standard GTS GSM 03.40.

It is possible to restrict the use of the transport part by authenticating the user of the transport part before its use. This is implemented e.g. by applying a procedure in which the sender has to input his personal identification number (PIN) before the transport part performs any of the above- described actions for the generation of a contract message. The transport part contains stored authenti- cation information relating to its users, and a permission to use the transport part is given on the basis of this information. Furthermore, the contract overlay with the information filled in can be presented to the user before the generation of the contract message. It is further possible to request the user to give an ap- proval of the contract message to be generated. 'Approval' means e.g. that the user gives permission to send the contract message by sending a predetermined data item to the transport part. 'Predetermined data item' means e.g. a PIN code. In a preferred embodiment, a sender certificate is added to the information to be transmitted to the receiver.

The invention also concerns a method for the reception of a concluded digital contract over a tele- communication network between two parties, said telecommunication network and/or parties comprising at least a transport part and an application part, in which method the contract comprises at least the contracting parties, an object of agreement, a contract overlay to be used and contract data and in which method the contract has been approved with a digital signature .

In the method of the invention, a contract message is received in a transport part. The contract message is preferably included in a short message in a mobile communication network. If the contract message could not be sent in a single short message, it can be divided into several short messages in accordance with the ETSI standard GTS GSM 03.40. From the contract message, a header section is resolved. The header section contains the receiver data, the sender data and the object of agreement. Further, the data section of the contract message received is resolved. If the data section has been encrypted, then it is decrypted be- fore being resolved. Stored in the transport part is a secret signing key and/or a secret decryption key. 'Resolving the data section' means e.g. that the par- titions of a hashed data section are sorted out and the information contained in the partitions is converted back into the original input data. 'Original input data' means the information used in the genera- tion of the hashed data section.

The use of the transport part can be restricted by authenticating the user of the transport part before its use. This is implemented e.g. by applying a procedure in which the sender has to input his personal identification number before the transport part performs any of the above-described actions for the resolution and verification of the contract message. Stored in the transport part is authentication information relating to its users, and a permis- sion to use the transport part is given on the basis of this information.

Based on the resolved header section, the contract overlay is retrieved. The contract overlay is stored in the transport part or is otherwise available to the transport part. In the above, it is assumed that both the sender and the receiver are already in possession of the contract overlay to be used in conjunction with the agreement. The contracting parties have agreed beforehand about a contract protocol, which defines the contract overlay to be used and the object of agreement. Object of agreement' refers e.g. to an identifier indicating a given application which processes the information relating to the contract. Further, the object of agreement can be used to indi- cate various operations that the transport part has to perform on the contract message it has received. The object of agreement may contain e.g. information indicating whether the message transmitted has been signed and/or encrypted, whether the message is time-critical or whether the contents of the message may be processed later, and so on. 'Receiver data' and 'sender data' contained in the header section preferably refer to a kind of network identity comprising encryption and/or signing keys which have been linked to it in conjunction with its generation. From the transport part, a connection can be established to a trusted third party (TTP) , from which the public keys associated with the network identities can be requested. 'Connection' may refer both to a connection oriented connection and a connectionless connection.

The resolved information is added to the con- tract overlay. The digital signature included in the contract message is verified. Further, the sender data, receiver data, object of agreement and message counter value are verified. If the result of the verification is acceptable, then the sender data, receiver data and object of agreement are transferred to the application part. If one of the above-mentioned verifications did not produce the desired result, then the contract message received may be rejected. The object of agreement defines e.g. the application to which the transferred information is to be transmitted.

In an embodiment of the invention, the sender of the received contract message has included his own certificate in the contract message. By means of the certificate, it is possible to ascertain that the sender is actually the person he claims to be.

In an embodiment of the invention, the sender of the contract message is sent a message acknowledging receipt of the contract message, said acknowledgement message containing e.g. the signature of the ac- knowledging party.

The present invention allows the amount of data to be transmitted in conjunction with a digital contract to be considerably reduced, yet without any detriment whatsoever to the level of security of the information transmitted or the legal competence of the contract. In the method of the invention, only the essential information contained in the contract is transmitted, without at all transmitting the framework structure itself of the contract.

A further advantage of the invention is that the application layer receiving the final information can be implemented in a simple and effective manner as it does not have to take care of matters relating to signature and/or encryption of the information.

The invention obviates the need for the contracting parties to establish a contact in time or place with each other. The contract can also be provided with a separate time stamp, and it can be confirmed via an external system, e.g. a notary service.

A further advantage of the invention is that the routing of the contract message, the object of agreement and the identity are based on the same identifier, thus advantageously preventing errors of interpretation of the contract. An error of interpretation may arise e.g. when the signatory of the contract and its provider are different identities. Yet another advantage of the invention is that it uses a message counter, which makes it possible to prevent repeated transmissions of the message. If the contract is transmitted in a short message and the contract is too large to be transmitted in a sin- gle short message, then it can be divided into several short messages. Even so, the value of the message counter is not changed.

LIST OF ILLUSTRATIONS In the following, the invention will be described in detail by the aid of a few examples of its embodiments, wherein:

Fig. 1 presents a flow diagram representing an example of methods according to the invention, Fig. 2 presents a preferred system in which a method according to the invention can be implemented, Fig. 3 presents flow diagram representing a preferred example of the generation of an equivalent of a digital contract,

Fig. 4 presents a flow diagram representing a preferred example in which the equivalent of a digital contract is signed digitally and encrypted,

Fig. 5 presents a flow diagram representing a preferred example in which the equivalent of a digital contract is decrypted, Fig. 6 presents a flow diagram representing a preferred example in which the authenticity of the decrypted information contained in a digital contract is verified, and

Fig. 7 presents a preferred digital contract.

DETAILED DESCRIPTION OF THE INVENTION

Fig. 1 illustrates the progress of the procedures of the invention. The figure presents both a procedure for sending a contract message and a proce- dure for receiving one. In the figure, the sender of the contract message is designated by the letter A and the receiver of the contract message by the letter B. 'A' is e.g. a terminal device with a user and 'B' is a service provider's data system. 'Service provider' re- fers e.g. to a bank and 'terminal device' to a mobile station.

According to block 1, the parties A and B agree about a contract protocol. B offers A a contract overlay and states an object of agreement. 'Object of agreement' preferably means an identifier pointing at an application maintained by B. The receiver data, contract data and object of agreement for the contract are transferred from the application part to the transport part, block 2. For the transport part, the application level data is only a constant string which is added to the contract. According to block 3, a header section is generated. The header section contains sender data, receiver data and the object of agreement. 'Sender data' and 'receiver data' preferably refer to a net- work identity comprising encryption and/or signing keys which have been linked to it in conjunction with its generation. From the transport part, a connection can be established to a trusted third party, from which the public keys associated with different net- work identities can be requested. 'Connection' may refer both to a connection oriented connection and to a connectionless connection. Based on the header section, the transport part retrieves the contract overlay, block 4. The contract overlay has been stored in the transport part or is otherwise available to the transport part .

According to block 5, the contract overlay is filled in with the information received from the application part. Moreover, the transport part adds to the contract overlay information known to it beforehand. The transport part determines for the contract a message counter to which it is possible to give certain pre-defined values. The use of the message counter will be discussed in examples to be presented later on. The contract overlay and the information filled in it can be presented to the user. Furthermore, the user may be required to express an approval of the information presented. 'Approval' means e.g. that the user has to input a predetermined code into his terminal device.

Based on the information filled in the contract overlay, the transport part generates a hashed data section, block 6. In generating a the hashed data section, the transport part may also use other infor- mation it has access to. The hashed data section is generated using e.g. a method according to PKCS#1 Version 2.1 or a method according to P1363. As stated in block 7, the header section generated before and the hashed data section just generated are combined to form a contract message to be transmitted. The contract message is signed e.g. by using the sender's se- cret signing key, block 8. The signed contract message can be additionally encrypted e.g. by using the receiver's public encryption key. From the transport part, a connection can be established to a trusted third party, from which a public encryption key asso- ciated with the receiver can be obtained. In addition, a sender's certificate can be appended to the contract message.

The signed and possibly encrypted contract message is finally transmitted to the receiver defined in the header section. The contract message is preferably transmitted in a short message in a mobile communication network. If the contract message is too large to be sent in a single short message, it can be divided into several short messages according to ETSI standard GTS GSM 03.40.

When B receives the contract message sent by A, it resolves the contract message, block 9. Resolving the contract message means that, from the contract message received, the header section is resolved, and from the header section again are resolved the receiver data, sender data and object of agreement. Next, B resolves the data section of the contract message. If the data section has been encrypted, then it is decrypted before being resolved. Stored in the transport part is a secret signing key and/or a secret decryption key. 'Resolving the data section' means e.g. that the partitions of the hashed data section received are sorted out and the information contained in the partitions is converted back into the original input data. 'Original input data' means the information used in the generation of the hashed data section. According to block 10, based on the header section, the contract overlay is retrieved. The contract overlay has been stored in the transport part or is otherwise available to the transport part. The re- solved information is added to the contract overlay retrieved, block 11. The digital signature attached to the contract message is verified. Further, the sender data, receiver data, object of agreement and the value of the message counter are verified, block 12. If the result of the verification is acceptable, then the sender data, contract data and object of agreement are transferred into the application part, blocks 13 and 14. If the result of any one of the above-mentioned verifications is unsatisfactory, then the contract message received may be rejected, blocks 13 and 15.

From the receiver's transport part, a connection can be established to a trusted third party to obtain the public keys associated with the sender of the contract message. 'Connection' may refer to a con- nection oriented connection or to a connectionless connection. The sender of the contract message may have included his own certificate in the contract message. In that case, the public key needed for the verification of the digital signature is included in the certificate, so a connection to a trusted third party need not necessarily be established. B may also send A an acknowledgement message to confirm receipt of the contract message sent by A. The acknowledgement message contains e.g. the signature of the acknowledg- ing party.

Fig. 2 presents a preferred system in which the method of the invention can be implemented. The system comprises a subscriber identity module SIM and a message gateway MSGW. The subscriber identity module SIM is preferably connected to a mobile station. The subscriber identity module SIM comprises an application part APP1, which in this example means a browser application. The browser application presents the digital contract to the user of the mobile station, who then fills in the required information in the contract . In this example, a part of the subscriber identity module SIM and the message gateway MSGW together form a transport part TRANS . From the transport part TRANS, a connection is provided to a trusted third party TTP, whose function is to maintain a data- base in which the public encryption and/or signing keys associated with the contracting parties can be checked.

In the transport part TRANS, an equivalent of the digital contract is generated, signed and possibly encrypted, and the contract message thus produced is transmitted from the sender to the receiver. The telecommunication connection CONN represents the telecommunication network in which the message pertaining to the digital contract is transmitted. ' Telecommunica- tion network' preferably refers to a mobile communication network and 'message to be transmitted' means a short message in the mobile communication network.

The message gateway MSGW comprised in the transport part TRANS receives the contract message generated by the subscriber identity module SIM. The message gateway MSGW resolves the received message and verifies the authenticity of the sender and the message. Next, the message gateway MSGW only transmits predetermined partitions of the resolved message to the application part APP2 communicating with the message gateway MSGW. Application part APP2 means e.g. a Legacy system or equivalent. 'Legacy system' refers to a traditional computer system, such as e.g. the mainframe computer system of a bank or stock exchange. Fig. 3 presents a preferred example of the manner in which a hash of a digital contract is gener- ated from the information contained in the digital contract .

In the following, an algorithm used to generate Ml and Me will be presented. Listed below are the input data used in the algorithm and the results produced by it .

Input data:

• X; string to be encoded

• 1; length of X in octets • mc; 24-bit (3-octet) unambiguous identification data (message counter) of the contract

Results : • Me; that part of the information contained in the contract which does not fit in the part to be signed

• meLen; length of Me in octets

• Ml; information content attached to the contract overlay

In the following, the operation of the algorithm used to generate Ml and Me is described: 1. If 1 <= msLen

2. /*message to be encoded fits in RSA block*/

3. Me : = " "

4. meLen : = 0

5. Ml := IP20S(mc, meLen) || Padl423 (X, msLen+1) 6. Else

7. Ml := IP20S(mc, meLen) || Padl423 (X [1..msLen] , msLen+1)

8. Me :=X[msLen+l..1]

9. meLen :=1 - msLen lO.Endif

The action of IP20S (Nonnegative Integer to Octet String Primitive) is defined in greater detail e.g. in the document PKCS#1 : RSA Cryptography Standard. Version 2.0; RSA laboratories. October 1, 1998. The Padl423 primitive is used for the generation of an unambiguous padding in the message. Padl423 is defined in the document RFC1423 (RFC, Request For Comments) .

An electronic equivalent of the contract is generated from the above-mentioned components (Ml, Me, S3Hdr and M2) . A contract structure is thus produced in which part of the data in Ml can be masked. From Ml, S3Hdr, Me, M² and a seed, a hash code is computed by a hash function using a constant parameter ConstC. The hash function is represented by MAMGF1 (MAMGF, Multiple Arguments Mask Generation Function) . MAMGF1 generates a mask of arbitrary length from an arbitrary number of arguments using the SHAl algorithm (SHA, Secure Hash Algorithm) . From the hash w produced, a mask is computed by a hash function using a constant parameter ConstD. The seed and Ml are added to this mask using a XOR function (XOR, exclusive OR; sign Θ) . The result is an encoded equivalent T of the contract.

Below, the input data and results of the message generating algorithm are presented. Input data:

• Ml; information content attached to the contract overlay, with a message counter added to it. The operation and structure of the message counter will be discussed in a later example.

• Me; that part of the information content of the contract which does not fit in the part to be signed.

• S3Hdr; header section of the contract, indicating, among other things, the computer program to process the contract . In this example, S3Hdr consists of three partitions : • 40-bit sender and receiver identification data

• 12 -bit application pointer (APTR)

• 1-bit partition indicating whether the message is an encrypted/unencrypted one

• M2 ; unencoded, signed shared data which can be sent to both parties completely independently of the message. M2 is generated e.g. from the following check data: contract model check data, check data of the law to be applied, and check data of regulations and instructions.

• Seed; random string of a length of 20 oc- tets.

Result :

• T; string comprising Ml and a hash of parameters Ml, Me, M2 and S3Hdr Here is a description of the operation of the message generating algorithm described above:

1. seed := random string having a length of 20 octets

2. w := MAMGF1 (ConstC, seed, Ml || Me, S3Hdr I I M2) [wLen]

3. expandedW : =MAMGF1 (ConstD, w) [modLen-1- wLen]

4. seedMask : =expandedw [1.. seedLen]

5. mlMask : =expandedW [seedLen+1..modLen-1- wLen]

6. maskedSeed : =seed θ seedMask

7. maskedMl : = Ml θ mlMask

8. T -. = w || maskedSeed | | maskedMl

The parameters appearing above, mainly shown in square brackets, are defined as follows:

• modLen = 128 octets (=length of signing key in octets) • wLen = 20 octets

• hLen = 20 octets; length of the result produced by the hash function

• seedLen = 20 octets • ConstC = constant used in generating the mask

• ConstD = constant used in generating the mask

• meLen = 3; unambiguous identification data (message counter) identifying the contract

• msLen = modLen - wLen - seedLen - meLen - 2 = 83

Fig. 4 illustrates a preferred method whereby a hash generated from a digital contract can be signed and encrypted. The equivalent T of the digital contract, obtained as a result of the example presented in Fig. 3, is first signed with the sender's secret signing key utilizing the RSA algorithm (RSA, Rivest, Shamir, Adleman) , producing C as a result. After this, the signature can be additionally encrypted using the receiver's public encryption key and the RSA algorithm. Thus, the digital contract has been both signed and encrypted.

The notation and RSA primitives (RSASP1 and RSAEP in Fig. 4) used in the signature and in the possible encryption are defined e.g. in the document PKCS#1: RSA Cryptography Standard. Version 2.0; RSA laboratories. October 1, 1998.

Fig. 5 illustrates the decoding of a received equivalent T of a digital contract. At this stage, the equivalent T of the contract has already been decrypted if it had been encrypted, and the signature has been verified. The equivalent T of the contract has to be decoded to enable the message transmitted to be verified. In the decoding procedure, a mask is computed from the hash part T using a hash function MAMGFl and a constant parameter ConstD, which is combined via XOR with the latter part of T.

Below is a description of the operation of the decoding algorithm and the input data and results associated with the algorithm. Input data:

• T; received equivalent of digital contract

• Me; string that did not fit in the block signed with an RSA signature

Results :

• Ml; string included in the signature

• w; hash of the signed data

• mc; unambiguous identification data (mes- sage counter) identifying the contract

X; string originally encoded Seed used in the encoding

1. w :=T [1..wLen] 2. maskedSeed := T [wLen+1.. wLen+seedLen]

3. maskedMl : =T [wLen+seedLen+1..modLen-1]

4. expandedW : =MAMGF1 (ConstD, w) [modLen- wLen-1]

5. seedMask := expandedW [1.. seedLen] 6. mlMask := expandedW [seedLen+1..modLen- wLen-1] 7. seed : =maskedSeed θ mlMask

8. Ml = maskedMl θ mlMask

9. mc =0S2IP(M1 [1..meLen] ) 10. X = Stripl423 (Ml [mcLen+1..msLen] ) || Me A more detailed definition of the action of the 0S2IP (Octet String to Nonnegative Integer Primitive) is found e.g. in the document PKCS#1 : RSA Cryptography Standard. Version 2.0; RSA laboratories. Oc- tober 1, 1998. The Stripl423 primitive is used for deleting the padding created by Padl423 and it is defined in the document RFC1423. Fig. 6 illustrates an operation whereby the signature is finally verified. In the verification of the signature, the value of the hash w is computed from the decoded elements and compared with a trans- ferred/transmitted value. In this way, it will be established whether the contract in question was originally created by the signatory, i.e. the sender. Input data:

• w; hash encoded in the signature • seed; seed encoded in the signature

• C; string obtained as a result of execution of the RSAVP10 (the RSAVPlO primitive is more closely defined in the document PKCS#1: RSA Cryptography Standard. Version 2.0; RSA laboratories. October 1,

1998

• T; string C from which the first octet has been removed

• constC; constant used in generating the mask

• Ml; string included in the signature

• Me; the rest of the encoded string

• M2 ; string which was signed but which was not encoded at all • S3Hdr; S3SMSHdr, which was part of the signature

Result :

• Acceptance/Rejection of the signature

Here is a description of the operation of the algorithm used to verify the signature:

1. w' :=MAMGF1 (ConstC, seed, Ml || Me, S3Hdr I I M2) [20] 2. If C[l] != 0x01 then return "Invalid Signature" 3. If w' = w then return "Success Status".

Otherwise return "Invalid Signature" Fig. 7 presents an example of a contract from which a digital equivalent is generated. The contract in Fig. 7 comprises the following fields: object of agreement 71, sender data 72, receiver data 73, contract overlay 74, essential content of contract 75, signature 76 and message counter 77 associated with the contract. In accordance with the examples pre- sented above, an equivalent of the digital contract is thus generated on the basis of items 71 - 75 and 77 and the equivalent of the contract thus produced is additionally signed.

The unambiguous identification data 77 asso- ciated with the contract has an important function in the contract. 'Unambiguous' signifies that the identification data together with the sender data and receiver data constitutes an identifiable triad. The unambiguous identification data does not appear in the contract as a stochastic identifier or number; instead, it can be assigned various meanings beforehand. The unambiguous identification data can also be called a message counter.

' Sender data ' and ' receiver data ' preferably refer to a network identity. 'Network identity' means a global unambiguous identifier which is associated with certain keys for signature and encryption. The network identity is created e.g. by applying the following procedure : • an unambiguous identifier is generated from a key and/or keys associated with an encryption and/or signing method and from key holder information and/or other information; and • from the identifier, a hash is generated to form a pointer referring to the informa- tion from which the hash has been generated. The hashes thus produced are stored in a centralized location so that each identifier is unambiguously associated with a given juridical person.

The following message counter values can be assigned the meanings shown below:

A message with a triad (sender, receiver, message counter) having a given value is to be accepted for reception only once. The receiver has to increase the counter value by one each time the message is received. The default value of the message counter is 32. This means that the message has not yet been sent at all.

"Final" means that no message between a given sender and a given receiver should be accepted after a message having this message counter value has been transmitted. A message coming after this should be rejected even if it should have the message counter value "unique" .

The present invention satisfies the following requirements :

1. The signature authenticates the signatory.

2. The signature authenticates the data signed

3. The signature is a valid and binding expression of will regarding an intention 4. The original contract is restorable, in other words, part of the message is within the signature block

5. Variants of messages received can be de- tected

6. The coding must support signed and encrypted contracts and/or unencrypted contracts .

7. The method imposes no restriction on the length of the contract text

8. The signed data may differ from the coded data; the coded data may contain control characters which as such are not included in the contract itself. The invention is not restricted to the examples of its embodiments described above; instead, many variations are possible within the scope of the inventive idea defined in the claims.

Claims

1. Method for making and transmitting a digital contract over a telecommunication network between two parties, said telecommunication network and/or parties comprising at least a transport part and an application part, in which method the contract comprises at least the contracting parties, an object of agreement, a contract overlay to be used and contract data and in which method the contract is approved with a digital signature, charac t eri zed in that the method further comprises the steps of: transferring receiver data, contract data and object of agreement from an application part to a trans- port part; generating a header section in which are included receiver data, sender data and object of agreement; retrieving a contract overlay on the basis of the header section; completing the contract overlay by filling in the sender data, receiver data, contract data, object of agreement and a message counter associated with the contract ; generating a hashed data section using the fields filled in the contract overlay as a source; combining the header section and the data section into a contract message to be transmitted; digitally signing the contract message; and transferring the contract message thus generated to the receiver.

2. Method according to claim 1, c h a r a c t e r i z e d in that the user of the transport part is authenticated so that the user has a right to use the transport part .

3. Method according to claim 1 or 2, c h a r a c t e r i z e d in that a connection is set up from the transport part to a trusted third party, from which a public key associated with the receiver is retrieved.

4. Method according to any one of the preceding claims 1, 2 or 3, charac t er i z ed in that the hashed data section and/or the message to be sent are/is encrypted.

5. Method according to any one of the preceding claims 1, 2, 3 or 4, charac t e ri z ed in that the hashed data section is generated by a method according to PKCS#1 version 2.1, according to P1363a or by some other corresponding method.

6. Method according to any one of the preceding claims 1, 2, 3, 4 or 5, cha rac t e ri zed in that a public key method is used for the signature and/or encryption.

7. Method according to any one of the preceding claims 1, 2, 3, 4, 5 or 6, charac t e ri zed in that the contract is presented to the sender and an approval is required for the transmission of the con- tract.

8. Method according to any one of the preceding claims 1, 2, 3, 4, 5, 6 or 7, chara c t e r i zed in that the contract message generated is transmitted in a short message in a mobile communica- tion network.

9. Method according to any one of the preceding claims 1, 2, 3, 4, 5, 6, 7 or 8, charac t eri zed in that the transport part comprises the sender data, a secret signing key and/or a secret en- cryption key and authentication information about users having a right to use the transport part .

10. Method according to any one of the preceding claims 1, 2, 3, 4, 5, 6, 7, 8 or 9, char ac t eri zed in that a sender's certificate is added to the contract data to be transmitted to the receiver.

11. Method for receiving a digital contract over a telecommunication network between two parties, said telecommunication network and/or parties comprising at least a transport part and an application part, in which method the contract comprises at least the contracting parties, an object of agreement, a contract overlay to be used and contract data and in which method the contract is approved with a digital signature, charac t e ri zed in that the method further comprises the steps of : receiving the contract message into the transport part ; resolving a header section from the contract mes- sage; resolving receiver data, sender data and the object of agreement from the header section; resolving a data section from the contract message ; retrieving a contract overlay on the basis of the header section; adding the resolved data into the contract overlay; verifying the digital signature, sender data, re- ceiver data, object of agreement and message counter value associated with the contract message; and, if the result of the verification is acceptable, the step of transferring the sender data, contract data and object of agreement into the application part.

12. Method according to claim 11, char ac t eri zed in that the user of the transport part is authenticated so that the user has a right to use the transport part .

13. Method according to claim 11 or 12, charac t eri zed in that a connection is established from the transport part to a trusted third party, and public keys associated with the sender are retrieved from said third party.

14. Method according to any one of the preceding claims 11, 12 or 13, charac t e ri z ed in that, if the message received has been encrypted, the message is decrypted.

15. Method according to any one of the preceding claims 11, 12, 13 or 14, charact er i z ed in that the received contract message is re- jected if the result produced by the verification of the sender data, receiver data, object of agreement or the value of the message counter is not acceptable.

16. Method according to any one of the preceding claims 11, 12, 13, 14 or 15, cha rac t er - i z e d in that the sender data, contract data and object of agreement are transferred from the resolved contract message to an application part determined by the object of agreement.

17. Method according to any one of the pre- ceding claims 11, 12, 13, 14, 15 or 16, charac t e ri z ed in that the actions to be carried out on the received contract message are concluded in the transport part from the object of agreement.

18. Method according to any one of the pre- ceding claims 11, 12, 13, 14, 15, 16 or 17, char ac t e r i zed in that the transport part comprises the receiver data, secret signing key and/or secret encryption key and authentication information about users having a right to use the transport part .

19. Method according to any one of the preceding claims 11, 12, 13, 14, 15, 16, 17 or 18, charac t eri zed in that a sender's certificate transmitted in the contract data is verified.

20. Method according to any one of the pre- ceding claims 11, 12, 13, 14, 15, 16, 17, 18 or 19, charact e ri zed in that an acknowledgement mes- sage is sent to the sender of the contract message received.

21. Method according to any one of the preceding claims 11, 12, 13, 14, 15, 16, 17, 18, 19 or 20, characteri zed in that the contract message is received in a short message in a mobile communication network.