WO2008122688A1

WO2008122688A1 - Method, device, server arrangement, system and computer program products for securely storing data in a portable device

Info

Publication number: WO2008122688A1
Application number: PCT/FI2007/000091
Authority: WO
Inventors: Markku Suominen
Original assignee: Meridea Financial Software Oy
Priority date: 2007-04-10
Filing date: 2007-04-10
Publication date: 2008-10-16

Abstract

A piece of confidential data (C) is stored in encrypted form in a memory (102) of a portable device (101). A decrypting key needed for decrypting the piece of confidential data (C) is stored (115) in a service provider's system (111). A piece of encrypted digital data (KSIGN) is also stored in the memory (102) of the portable device (101), and all decrypted forms of both said piece of confidential data and said piece of encrypted digital are erased from the portable device (101). A piece of digital data that has a cryptographic one-to-one correspondence with said piece of encrypted digital data exists (114) in the service provider's system. When a user gives a passphrase, the encrypted digital data (KSIGN) is decrypted and used to cryptographically process a request message, which causes the service provider's system (111) deliver said decrypting key to the portable device.

Description

Method, device, server arrangement, system and computer program products for securely storing data in a portable device

The invention concerns generally the technical field of protecting stored digital data against unauthorised access and use. Specifically the invention concerns the secure storage of digital data in an unprotected memory of a portable electronic device.

In order to use a portable electronic device for confidential applications such as mobile banking or the like, a user must store into the memory of the device digital data than can be classified as secret or confidential. The stored data may comprise e.g. a digital certificate or a cryptographic key, which essentially serve as digital identification means. A party that can present a certain digital certificate at request, or a party that possesses and is able to use a certain cryptographic key, has access to data and services that otherwise would be unavailable for him. The stored confidential data may comprise e.g. a digital certificate according to the standard X.509, or one of the keys of an PKI (Public Key Infrastructure) arrangement.

Many portable devices, especially mobile telephones, comprise a so-called SIM (Subscriber Identity Module), an important part of which is a tamper-proof memory. Digital data stored within the SIM are inherently secure, because the SIM only allows accessing its contents if the user gives the correct PIN (Personal Identity Number) or passphrase, and permanently locks itself after a predefined (small) number of attempts with incorrect passphrase.

The drawback of SIMs and corresponding inherently tamper-proof storage means is that they are typically not accessible for other software than the proprietary, embedded operating system of the portable device, or at least not to all applications that would need safe storage of digital data. For example at the date of writing this description many portable communications devices offer a Java environment for running third-party software, but midlets that are executed in the Java environment are denied access to the secure storage capabilities of the SIM. A standard known as JSR-177 is known that would offer at least a partial remedy to the problem, but devices supporting said standard are only expected to appear on the market in the future. The straightforward solution for storing confidential digital data in an ordinary, unprotected memory is to store it in encrypted form, and to ask the user for a PIN or passphrase every time he wants to utilise the encrypted digital data. When the user gives his passphrase, a decrypting operation follows, which makes the confi- dential data available for the present need. After that the plaintext, decrypted form of the confidential data is erased, so that next time when it is needed it must be decrypted again after a new PIN enquiry.

The weakness of said straightforward solution is the requirement for sufficiently strong encryption, which in turn would require a large key space. It is not feasible to require a human user to memorize a very long passphrase. Typical PINs of present day are four-digit numbers, which means that not more than 10 000 different PINs exist, and the reasonable length limit of any convenient passphrase is not much higher. If correctly decrypting the encrypted but otherwise unprotected memory contents of a portable device only requires the appropriate four-digit PIN, it is relatively easy to crack the protection by downloading the whole encrypted memory into a powerful enough computer and trying all possible PINs until a result is obtained that appears to contain meaningful information.

The degree of security that can be achieved with a particular key depends on the quality of the encrypting algorithm, the amount of computing capacity that is avail- able for the cracking attempt, as well as the time frame in which the encrypted data loses its relevance. At the time of writing this description a 128-bit key is generally regarded as essentially unbreakable, provided that a high-quality encryption algorithm such as AES (Advanced Encryption Standard) and good key generation norms such as FIPS 140-2 (where FIPS means Federal Information Processing Standards) are used. Increasing the key length adds security, because each new bit position in the key doubles the time required for a brute-force breaking attempt to succeed.

Yet another class of solutions exist, in which the user does not give a character string as a passphrase but allows the device to read a biometric identifier, such as a fingerprint. These solutions require complicated hardware, and are thus inherently much more costly and more difficult to implement in practice than passphrase-based solutions.

An objective of the present invention is to enable safely storing confidential digital data in the unprotected memory of an electronic device, without requiring users to memorize and give overly long passphrases. The objectives of the invention are achieved by storing confidential information encrypted with a strong encryption algorithm, the long decryption key of which is stored at a protected server, and only allowing a limited number of access attempts to said protected server. A signing key is required for making an access at- tempt, said signing key having also been stored in encrypted form only. A dishonest user may only test his success in decrypting a signing key by making the access attempt, and the protected server will block further attempts after a small number of unsuccessful guesses.

A method according to the invention is characterised by the features recited in the characterising part of the independent claim directed to a method.

A portable device according to the invention is characterised by the features recited in the characterising part of the independent claim directed to a portable device.

A server arrangement according to the invention is characterised by the features recited in the characterising part of the independent claim directed to a server arrangement.

Computer program products according to the invention are characterised by the features recited in the characterising parts of the respective independent claims directed to computer program products.

A basic insight behind the present invention is that encrypted digital data is only vulnerable to brute force attacks if the attacker can verify after each attempt whether he succeeded or not, and can continue trying until he succeeds. This means that the correctly decrypted "plaintext" data must be good for something. If the plaintext data included words of some comprehensible language, a measure of success is whether a comparison between the decrypted result and some general vocabulary produces any matches. If the plaintext data was itself a decryption key, applying it to some further decrypting operation must in turn provide comprehensible results, and so on.

An important building block of the present invention is a practice, according to which the only way in which an attacker can verify the success of his possible brute force attempt is to use the decrypted result to access a service, pretending to be the legal user of that service. The provider of said service will only allow a very limited number of unsuccessful attempts, after which all further attempts by that user (legal or pretender) are blocked. The small number of allowable failures means that a brute force attacker makes it to only browse through a meaningless fraction of the possible key space before the service provider reacts. This in turn means that the key space does not even need to be very large, i.e. the passphrase, which the user must memorize and give, is not very long.

According to a further aspect of the present invention, the service is not just any service but storage of the actual, long key(s) that the user needs for properly decrypting some further piece of confidential data, which he has in his own possession or will acquire. A strong encryption algorithm and a long key protect the confidentiality of this further piece of data. Still, the user does not need to memorize or give said long key, because he can obtain it every time from the secure storage maintained by the service provider. Actually the user does not need to even know about the existence of a long key, because the devices and software involved will handle the long key in a completely automatic fashion.

When a user wants to decrypt a piece of strongly encrypted digital data, he gives a relatively simple passphrase. The portable device uses this passphrase or a derivative thereof to decrypt a so-called request key or signing key, which is a key of a symmetric cryptographic system or constitutes one half of a key pair of an asymmetric cryptographic system. In the case of a symmetric system, another copy of said key only exists in the possession of a service provider's system. In the case of an asymmetric system, the other half of said key pair only exists in the possession of a service provider's system. The portable device forms a request, signs at least a part of it with the signing key and sends the signed request to the service provider.|

The service provider's system uses its own copy of the key or its own half of the key pair to verify that the request came from the legitimate party. After that the service provider's system fetches a stored strong key that was indicated in the request, and transmits it to the user's portable device. This transmission takes place through a properly protected transmission channel. The portable device uses the strong key or a derivative thereof to decrypt the actual piece of strongly encrypted digital data, the need of which initiated the whole process. The decrypted result or derivatives thereof may then be used for any purpose for which confidential data is needed, for example to authorise a transaction.

The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb "to comprise" is used in this patent application as an open limita- tion that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.

The novel features which are considered as characteristic of the invention are set forth in particular in the appended claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings.

Fig. 1 illustrates an arrangement of a user's device and a service provider's server arrangement,

fig. 2 illustrates a procedure of events in retrieving a decrypted form of the confidential data from the memory of the portable device,

fig. 3 illustrates an exemplary way of delivering shared secrets and personalized client programs to the user's device and

fig. 4 illustrates an alternative key generator for the arrangement of fig. 3.

Fig. 1 illustrates schematically certain devices and functionalities of a system according to an embodiment of the invention. The device 101 is preferably a user's portable terminal equipped with inherent communications capabilities, like a multifunctional portable terminal of a cellular communications system or a portable computer capable of wireless communications. It may be also a personal workstation with a wired network connection. The device 101 comprises a memory 102, which does not need to have any inherent security features. For example, the memory 102 may be the RMS (Record Management System) memory of a portable terminal.

Stored in the memory 102 are, among others, two pieces of encrypted digital data. The first of these is here called the signing key KSIGN- It is stored in encrypted form in the memory 102, but it does not need to be strongly encrypted. Strong encryption is here considered to be one that is regarded as impossible to break with a brute force attack; at the time of writing this description an example of strong en- cryption is AES with a 128-bit key selected according to FIPS 140-2. The following conditions apply to the "weak" encryption of the signing key KSIGN: 1 ) It only requires a relatively short passphrase for decrypting. The shortness of the passphrase is a relative concept, but it should be understood to mean a passphrase length that a majority of human users will consider to be short enough to conveniently memorize and input to an electronic device.

2) Attempted decrypting of the encrypted signing key KSIGN with an incorrect passphrase gives something that appears to be a correctly decrypted signing key. In other words, by only looking at the result of a decrypting attempt it is impossible to tell, whether the attempt was successful or not. This condition is easiest to fulfil if the decrypted form of the signing key K_SIGN is a passage of pseudorandom data.

3) The passphrase that is required for correctly decrypting K_SIGN is one that is easy to give with the commonly used input means of devices like the exemplary device 101. Since the common feature of most portable terminals of present day is a numeric keypad, this condition is easiest to fulfil if the passphrase is a string of digits.

It should be noted that the passphrase, which a user will give, is not necessarily the same as the cryptographic element that an algorithm uses to decrypt the signing key K_SIGN- In order to keep the terminology consistent, we will reserve the term "passphrase" to mean a piece of input which a human user gives to the device 101 , and use the designation "weak decryption key" and the notation U_PAss to indicate the cryptographic element that an algorithm uses to decrypt the signing key KSIGN- U_PAS_S is a derivative of the passphrase. For example, UPASS may be an AES key obtained by performing a logical XOR (exclusive-or) between a digital representation of the passphrase (or an SHA-256 hash thereof) and a bit string of required length that is common to all devices that utilise the present invention. Naturally the invention does not exclude using the passphrase or its hash directly as the weak decryption key.

The second piece of encrypted digital data that is stored in the memory 102 is here designated as the certificate C. According to the standard X.509 the certificate C may contain a private key, which is not shown in fig. 1 but which we may designate as the transaction key KCA- An alternative is that what in fig. 1 appears as the certificate C may be just the transaction key KCA- Whatever the nature of the second piece of encrypted digital data, it is stored in a strongly encrypted form, the strength of the encryption being illustrated graphically in the drawing with a double line. An exemplary strong encryption method is AES with a FIPS 140-2 key and key length of at least 128 bits, preferably 256 bits. The part of memory containing the second piece of encrypted digital data may be called the keystore 103, for which the acronym KS is frequently used. One possibility is to always keep the complete contents of a keystore 103 strongly encrypted, regardless of what data (if any) has been stored therein.

In order to decrypt the second piece of encrypted digital data, a strong key K_Ks is needed. Again, it is not necessarily the strong key K«s itself that an algorithm would use as the actual cryptographic element for decrypting; said actual cryptographic element, called here the "strong decryption key" K_SD, may be for example the result of an XOR operation between the strong key KK_S and a passphrase (or the hash of a passphrase) given by a user. An important safety rule is to never store the strong key K_Ks or the strong decryption key K_SD derived therefrom in the device 101 any longer than what is needed for an ongoing decrypting operation. The longer the time such an important cryptographic element is kept stored, the greater the possibility that an unauthorised party gets access to it in one way or another.

Fig. 1 shows also two functionalities of the device 101 , called the smart signer 104 and the transaction signer 105. These are typically software processes used to process and transmit requests and instructions for transactions. The purpose and operation of these processes will be discussed in more detail later. Additionally the device 101 comprises at least one transceiver 106.

A server arrangement in the service provider's system 111 comprises a network interface 112 adapted to arrange communications with users' devices, as well as a request handler 113 and storage means, which in fig. 1 appear as a verification key storage 114 and a strong key storage 115. The purpose of the former is to store the keys that have one-to-one correspondence with the signing keys that ex- ist in the users' devices. In the case of a symmetric cryptographic system this means exact copies of the users' signing keys; in the case of an asymmetric cryptographic system this means the other halves of the key pairs of which one half exists in the users' devices.

When a signed request comes from a user's device, the request handler 113 veri- fies the signature with the corresponding key or the corresponding other half of the key pair, read from the verification key storage 114. After successful verification the request handler 113 fetches the appropriate requested strong key from the strong key storage 115 and transmits it to the requesting user's device. The network interface 112 comprises the necessary means for setting up and maintaining the secure connections that are needed for exchanging confidential information with users' devices.

The service provider's system 111 is also shown to comprise a transaction handler 116. We may assume that the final purpose of a user is to perform a transaction, which will be handled by the transaction handler 116 but which will only succeed if the user is able to correctly decrypt and utilise the second piece of encrypted digital data stored in the memory 102 of the user's device 101. It is not necessary to have the transaction handler 116 in the same system as the request handler 113 and the storage means 114 and 115; indeed the transaction that the user wishes to perform may take place in communication with a completely different service provider and a respective completely different service provider's system.

Fig. 2 illustrates an exemplary sequence of events that may take place in the system of fig. 1. As an exemplary division of work, we assume that the user's device comprises an application program that organizes the proceeding of events, as well as a smart signer program that performs specific tasks related to request messages, and a transaction signer program that performs specific tasks related to transactions. This division is naturally only an example, and the corresponding functionalities could be arranged in the user's device in a number of alternative ways.

At step 201 the user gives a command to the user's device to launch an application needed to perform a transaction. If required, step 201 may require the user to give a PIN number or other user-specific code that the application requires in order to begin execution. At step 202 the user's device informs the user that a passphrase is needed before the transaction can be performed. There may have been other steps between steps 201 and 202, in which the user has defined, what kind of a transaction he would like to perform.

At step 203 the user gives his passphrase. The user's device forwards the passphrase to the smart signer, which utilises the passphrase to derive a weak decryption key at step 204. As explained earlier, in the most simple case step 204 only means taking a digital representation of the passphrase for use as the weak decryption key, while more complicated alternatives include (but are not limited to) calculating a hash from the digital representation of the passphrase and making an XOR operation between the hash and some default bit string. At step 205 the smart signer utilises the weak decryption key to decrypt a signing key KsiGN, which it had fetched in encrypted form from the memory of the user's device. At step 206 the smart signer composes a request message, which is meant to indicate to a service provider's system that the user needs a particular strong key. The actual composing of the request message may have been effected already earlier, for example between steps 201 and 202. What the signing key KsiG_N is really needed for is step 207, in which the user's device signs the request message. The general process of digitally signing a message is well known from standard PKI literature. For the purpose of the present invention it suffices to assume that at step 207 at least a part of the request message composed at step 206 is processed, using the signing key KSIGN, SO that respective reverse processing is only possible for a party that possesses either the same key (in the case of symmetric cryptography) or the other half of the key pair of which the signing key KSIGN is the first half.

At step 208 the smart signer returns the complete signed request message to the application, which transmits it to the service provider's system at step 209. The request handler in the service provider's system recognises the user account which is concerned at step 210, and finds the corresponding verification key (the same key or the "other half mentioned above) and verifies the signature at step 211. If the signature could not be verified, operation stops here, because a failure in verification indicates that the user had given an incorrect passphrase at step 203 either by mistake or because he was not the legitimate user and did not know the correct passphrase.

We assume that verification succeeded at step 211. At step 212 a secure commu- nications connection, such as a known SSL (Secure Sockets Layer) connection, is established between the user's device and the service provider's system. This could have been effected already earlier, for example so that already the transmission at step 209 could have taken place through the secure connection. At step 213 the request handler fetches the requested strong key K«s, and at step 214 it transmits it through the secure connection to the user's device.

Having received the strong key K«s, the application in the user's device forwards it to the transaction signer at step 215, which utilises the strong key K«s at step 216 to derive the strong decryption key KSD- Again as explained earlier, in the most simple case step 216 only means taking the strong key KKS for use as the strong decryption key K_SD_> while more complicated alternatives include (but are not limited to) possibly prompting the user to give his passphrase again (or reading the passphrase given earlier at step 203 from temporary storage), calculating a hash from the digital representation of the passphrase (or reading the hash calculated earlier at step 204 from temporary storage) and making an XOR (eXclusive-OR) operation between the hash and the received strong key K«s-

At step 217 the transaction signer uses the strong decryption key K_SD to decrypt the contents of a keystore, including a certificate C and a transaction key KCA- At step 218 it composes a transaction message, the purpose of which is to give a service provider's system the command to perform a transaction. This might have been accomplished already earlier, even as early as between steps 201 and 202 or during the time it took to request and receive the strong key. At step 219 the user's device utilises the certificate C and/or the transaction key KCA to process the transaction message so that it becomes cryptographically protected. As a representative example, the user's device digitally signs the transaction message with the transaction key KCA-

At step 220 the transaction signer returns the complete, cryptographically protected transaction message to the application, which forwards it to the service provider's system at step 221. Step 222 includes checking the integrity of the transaction message and verifying the signature, and if these succeed normally, allowing the transaction to execute. Again it should be noted that the transmission of step 221 may go to (and consequently the actual transaction may take place at) somewhere completely different than the service provider's system from which the user requested and obtained the strong key at steps 209-214.

Digital signing typically means calculating a digital signature with some suitable one-way hashing algorithm, like the known HMAC (Hash Message Authenticating Code). More security could be added to the steps 209, 214 and 221 by using synchronized counters at both the user's device and the service provider's system. The counter values are preferably large integer values of 128 bits or more, and preferably proceed in pseudorandom order, so that by knowing one counter value a dishonest party that has somehow infiltrated the communication connection would still have difficulties trying to guess the next counter value. There may be different sequence counters for different kinds of transactions and different counters for uplink and downlink directions, or a single counter for all traffic between a particular user and a particular service provider, or any mixture between these two extreme limits. The value of a sequence counter is increased after each use for signing or signature verifying. The input values to the hashing algorithm are then the message data (or a predetermined part thereof), the counter value or a deriva- tive of the counter value obtained from the sequence counter, and at least a part of the key used for signing.

In order to account for possible reasons of slight unsynchronism in counters, it is advisable that if a verifying party can not recreate the correct signature with a sin- gle try, it experiments with a small number of other counter values that fit within a predetermined window of allowable counter values close to the value tried first. If one of these gives a match, the verifier tells its appropriate sequence counter to store that value as the current value. If none of the allowable counter values gives a match, the communicating parties should be alerted and prompted to find out the reason of unsynchronism.

At some previous stage, a setup phase has taken place, resulting in a state in which the user's device and a service provider's system have stored the appropriate keys, and the user's device possesses the cryptographic algorithms and other functionalities that are needed at the later stages of the procedure. We describe in the following an advantageous way of implementing the setup phase with reference to fig. 3. The parts and functionalities illustrated in fig. 3 are exemplary and have specific importance to performing the setup phase in an advantageous manner. Fig. 3 can be considered both as illustrating apparatus-type features and as illustrating certain method steps.

The purpose is to establish at least one shared secret and to equip the user's device 311 with both its copy of the shared secret(s) and the necessary client program it will need in further operation. In fig. 3 we have selected an approach in which the service provider's system generates the shared secret(s), which imposes a natural additional limitation that it must be delivered to the user's device 311 as safely as possible. Specifically, we assume that the shared secrets are comparable to the signing key KSIGN and the certificate C mentioned above.

A generator 302 in the service provider's system 301 generates the shared secrets (i.e. the keys and certificates). These are stored as such to the service provider's confidential storage 303, which we assume to be heavily protected against any unauthorized access. The user's copy of the shared secrets is not sent to the user's device 311 in one piece but divided into two halves, most advantageously so that none of the halves is as such a complete key or certificate. One of these halves is "baked into" a client program that will be delivered to the user's terminal. We call it personalizing the client program; in fig. 3 there is illustrated schemati- cally a client program personalizer 304, which receives the appropriate half of the shared secrets from the generator 302 and uses it to personalize a generic client program read from a client program storage 305. The remaining half that was not used for client program personalizing can be called the activation code.

The service provider's system 301 comprises first transmitting means 306 and second transmitting means 307 that transmit the activating code and the personalized client program respectively to the user's device 311. The implementation of said transmitter means is not important to the invention but depends merely on the selection of a first channel 321 and a second channel 322 that will be used for transmission. Since the second channel 322 must convey a personalized client program, it must be a channel that is applicable for easily transferring a whole digital file. Typically the second channel 322 involves a wireless data connection, a short-distance data downloading connection (cable, Bluetooth, infrared or the like), a portable memory means, or any combination of these. Since performing the setup phase requires securely authenticating both parties to each other, it is not unreasonable (but also not mandatory, if the required level of security is reached otherwise) to require that it takes place physically at the premises of the service provider or his authorized representative.

The first channel 321 must only convey a relatively short activation code, typically a character string, which gives more freedom in selecting the type of the channel. The activation code could be shown to the user on a piece of paper or on a screen, or it could be transmitted over the Internet or any other long-distance communications network, or the like. For maintaining the security of the setup phase it is advisable that the first and second channels 321 and 322 differ enough from each other to make it improbable that a dishonest party could have infiltrated both of them simultaneously.

The user's device 311 receives the activation code through first receiving means 312 and the personalized client program through second receiving means 313. Again, the actual implementation of receiving means is not important to the invention and only depends on the selection of the channels. The second receiving means 313 could be for instance a long-distance or short-distance data communications transceiver, and the first receiving means 312 could be for instance a short messaging receiver or even as simple as a keypad through which a user will input an activation code he has seen on paper or on a web page. The user's device stores the received client program into a client program storage 314. There are basically two options: either the second half of the shared secrets only gets stored along with the personalized client program in the form it was received, or - as we have assumed in fig. 3 - alternatively or additionally the user's device extracts the second half from the personalized client program and combines it with the first half (i.e. the activation code) in a combiner 315 to get the original shared secret(s). In the first option mentioned above the combiner 315 is a triviality and what ends up at the encrypter 316 is only the activation code. In any case, the en- crypter encrypts the shared secret(s) it received, using a confidential passphrase that the user gives through passphrase input means 317. We should note that block 317 in fig. 3 may physically be the same as e.g. block 312, especially if it is a keypad.

The user's device stores the encrypted shared secrets in storage 318 and erases all plaintext forms of them from its memory. The last-mentioned action, as well as the fact that the storage 318 does not need to be a secure, protected piece of memory, is closely related to the principle of not having any means available for a possible dishonest party to test his success in brute-force cracking of encryption.

The fact that there are at least two shared secrets, which in the description above have appeared as the signing key KSIGN and the certificate C, may affect the procedure of events in fig. 3 in various ways. Above we suggested that both shared secrets could be delivered to the user's device during a single run through the described events. It is also possible to deliver them in two different procedures, so that the signing key KSIGN is delivered in two halves, one of which is used to personalize a smart signer program, and the certificate C is separately delivered in two halves, one of which is used to personalize a transaction signer program. It is also possible the apply the procedure of fig. 3 to only delivering one of said two shared secrets and to deliver the other to the user's device in some other way.

Fig. 4 illustrates an alternative key generator 302' for use in a service provider's system, if asymmetric cryptography is used. The key generator 302' is adapted to generate at least one key pair of an asymmetric cryptographic system. One key of the key pair remains in the keystore of the service provider's system, and the other key of the key pair is further divided into two parts, one of which is transmitted directly to the user while the other is used for personalizing a client program. Neither key of the key pair is made public. It should be noted that asymmetric cryptography arrangements require more memory and processing capacity than symmetric ones, which makes the symmetric cryptography approach of fig. 3 quite advantageous in many application environments. The exemplary embodiments explained above should not be construed to place limitations to only specific embodiments named. For example, the user's portable device does not need to be a cellular telephone, although at the time of writing this description a cellular telephone is by far the most common portable communica- tions apparatus that people carry around all the time, which makes it a good choice for a user's device because the user would not need to acquire any additional hardware. Another point of the invention where terminology should not be understood to cause unnecessary limitations is the step of giving a passphrase, which does not necessarily mean pressing some keys in appropriate order. It could refer to other forms of inputting information, including letting the user's device read a biometric identifier of the user.

Claims

1. A method for securely storing data into a portable device (101), comprising: - storing (318) a piece of confidential data (C) in encrypted form into a memory (102) of the portable device (101), and - storing (303) a decrypting key needed for decrypting the piece of confidential data (C) into a service provider's system (111 ) that is different from the portable device (101), the decrypting key being available at request;

characterized in that it comprises

- storing (318) a piece of encrypted digital data (K_SIGN) into the memory (102) of the portable device (101) and erasing all decrypted forms of both said piece of confidential data (C) and said piece of encrypted digital data (KSIGN) from the portable device (101), and

- storing (303) a piece of digital data that has a cryptographic one-to-one correspondence with said piece of encrypted digital data (KSIGN) into the service pro- vider's system (111);

wherein decrypting the encryption of said piece of encrypted digital data (KSIGN) requires a user to give a passphrase to the portable device (101 ), and wherein the service provider's system (111) is made responsive to a request cryptographically processed with a decrypted form of said piece of encrypted digital data (KSIGN), SO that a response to such request comprises delivering said decrypting key to the portable device (101).

2. A method according to claim 1 , characterized in that said piece of encrypted digital data (K_SIGN) is an encrypted digital signing key, and said piece of digital data that has a cryptographic one-to-one correspondence with said piece of encrypted digital data (KSIGN) is a digital signature verification key that corresponds to said digital signing key (KSIGN), SO that the service provider's system (111) is made responsive to a request that is digitally signed with a decrypted form of said digital signing key.

3. A method according to claim 1 , characterized in that at least one of storing the piece of confidential data in encrypted form into the memory of the portable device (101) and storing a piece of encrypted digital data into the memory of the portable device (101) comprises: - generating (302) and storing (303) a shared secret within the service provider's system (111),

- delivering (306, 312, 321) a first part of the generated shared secret to said portable device (101), - personalizing (304) a client program by including a second part of the generated shared secret, different than said first part, into said client program, and delivering (307, 313, 322) the personalized client program to said portable device (101) through a different delivery channel (322) than what was used for delivering the first part of the generated shared secret, and - combining (315) the first part and the second part of the shared secret in the portable device (101), encrypting (316) the result of said combining and storing (318) the encrypted result into a memory of the portable device (101 ).

4. A method for a portable device (101) for retrieving a decrypted form of a piece of confidential data (C) stored in encrypted form in a memory (102) of the portable device (101), comprising requesting (209) and receiving (214) a decryption key needed for decrypting the piece of confidential data from outside the portable device (101 ), characterized in that it comprises:

- receiving (203) a passphrase from a user of the portable device (101),

- using (204, 205) said passphrase to decrypt a piece of encrypted digital data (K_SIGN) stored in the memory (102) of the portable device (101 ),

- generating (206) a request message and cryptographically processing (207) said request message using the decrypted piece of digital data,

- transmitting (209) the cryptographically processed request message to a service provider's system (111), - receiving (214) a decrypting key from said service provider's system (111 ) and

- using (216, 217) the received decrypting key to decrypt the piece of confidential data (C).

5. A method according to claim 4, characterized in that said piece of encrypted digital data (KSIGN) is an encrypted digital signing key, and cryptographically proc- essing (207) said request message comprises digitally signing said request message using a decrypted form of said digital signing key.

6. A method according to claim 4, characterized in that said piece of confidential data (C) is a digital certificate, and the method comprises, after having decrypted the digital certificate, using the decrypted digital certificate to authenticate (218, 219, 220, 221) a user of the portable device (101) in the course of commanding a remote system to perform a transaction (222).

7. A system for securely storing data in a portable device (101), the system comprising:

- a portable device (101 ) having a transceiver (106) and a memory (102) for storing a piece of confidential data (C) in encrypted form, - a server arrangement (111) having a network interface (112) for communicating with the portable device (101) and a key storage (115) for storing a decrypting key needed for decrypting the piece of confidential data (C),

characterized in that:

- the portable device (101) is adapted to store a piece of encrypted digital data (KSIGN) and to erase all decrypted forms of both said piece of confidential data (C) and said piece of encrypted digital data (KSIGN) from the portable device (101 ),

- the server arrangement (111 ) is adapted to store a piece of digital data that has a cryptographic one-to-one correspondence with said piece of encrypted digital data

(KSIGN), - the portable device (101 ) is adapted to require a user to give a passphrase, to decrypt the encryption of said piece of encrypted digital data (KSIGN) using a given passphrase and to generate and cryptographically process a request message using a decrypted form of said digital data, - the server arrangement (111) is adapted to verify a request message received from the portable device (101) and to respond to a verified request message by delivering said decrypting key to the portable device (101), and

- the portable device (101 ) is adapted to decrypt the piece of confidential data (C) using the decrypting key delivered by the server arrangement (111 ).

8. A portable device (101 ) for securely storing data, comprising a transceiver (106) and a memory (102) for storing a piece of confidential data (C) in encrypted form, characterized in that:

- the portable device (101 ) is adapted to store a piece of encrypted digital data (KSIGN) and to erase all decrypted forms of both said piece of confidential data (C) and said piece of encrypted digital data (KSIGN) from the portable device (101), - the portable device (101 ) is adapted to require (202) a user to give a passphrase, to decrypt the encryption of said piece of encrypted digital data (KSIGN) using a given passphrase and to generate and cryptographically process a request message (209) using a decrypted form of said digital data, and to transmit the cryptographically processed request message to a service provider's system (111), and - the portable device (101 ) is adapted to receive (214) a decrypting key from said service provider's system as a response to transmitting the cryptographically proc- essed request message, and to decrypt the piece of confidential data (C) using the decrypting key delivered by the service provider's system.

9. A portable device (101 ) according to claim 8, characterized in that in order to receive and store at least one of said piece of confidential data and said piece of digital data it comprises:

- a first receiving means (312) and a second receiving means (313),

- a combiner (315) adapted to combine a first part of a shared secret received through said first receiving means (312) and a second part of a shared secret received through said second receiving means (313) and

- an encrypter (316) adapted to encrypt an output of said combiner and to store an encrypted result into a memory (102).

10. A portable device (101 ) according to claim 8, characterized in that the memory (102) that is adapted to store said piece of confidential data (C) in encrypted form and said piece of encrypted digital data (K_SIGN) is an unprotected memory.

11. A computer program product for a portable device (101 ) for securely storing data in the portable device (101), comprising computer program means that, when loaded into a computer, cause the computer to store a piece of confidential data (C) in encrypted form, characterized in that it comprises:

- computer program means that, when loaded into a computer, cause the com- puter to store a piece of encrypted digital data (KSIGN) and to erase all decrypted forms of both said piece of confidential data (C) and said piece of encrypted digital data (KSIGN) from the computer,

- computer program means that, when loaded into a computer, cause the computer to require (202) a user to give a passphrase, to decrypt (204, 205) the en- cryption of said piece of encrypted digital data (KSIGN) using a given passphrase and to generate (206) and cryptographically process (207) a request message using a decrypted form of said digital data, and to transmit (209) the cryptographically processed request message to a service provider's system (111), and

- computer program means that, when loaded into a computer, cause the com- puter to receive (214) a decrypting key from said service provider's system (111 ) as a response to transmitting the cryptographically processed request message (209), and to decrypt the piece of confidential data (C) using the decrypting key delivered by the service provider's system (111).