On the Difficulty of Protecting Private Keys in Software Environments

Transcription

1 On the Difficulty of Protecting Private Keys in Software Environments Taekyoung Kwon Sejong University, Seoul , Korea Abstract. This paper makes simple observation on security of the networked cryptographic device resilient to capture that was developed to protect user s private keys by software-only techniques. That scheme provided valuable features for secure generation of digital signatures or decryption of messages in a way of retaining a password-protected private key in a user-controlled device. The key idea was to exploit network connectivity rather than tamper-resistance of the device for securing the private key in software. However, we have found a few weak points that are not negligible in some sense. It was difficult to protect the private key in software even with provable security. So, we will describe such difficulties and provide possible solutions in this paper. Also the networked cryptographic devices will be augmented in that fashion. 1 Introduction Public key cryptography works well so long as a user knows intended recipient s public key in advance. A public key infrastructure (PKI) plays an important role for binding a public key to an entity in that sense. However, the security of public key cryptography depends upon the security of a private key as well. If the private key is compromised, all messages that are encrypted with its corresponding public key can be read. Also the compromised private key can be used to forge user s digital signature. So care must be taken to manage the private key in PKIs. However, the keying material is not favorable to human memory, so that a kind of storage device resilient to capture is required for securing user s private key[11]. It is obvious that a tamper-resistant device is a promising solution for the purpose because the private key can never leave the portable device, for example, a crypto smart card. However, such a device is still expensive and not ubiquitous at this time. From a different standpoint, the tamper-resistant device could have a surreptitious channel injected by someone at manufacturing time because it is supposed to be a black box of which the inside can never be verified by its users[3]. Also it can be vulnerable to the virus that infects user s computer to modify messages exchanged with the device[7].

2 2 T. Kwon Currently it is usual to encrypt the private key with a symmetric key derived from a mnemonic password and retain it in a user-controlled device such as a desktop computer, notebook and handheld, in software[16]. However, the storage device is not tamper-resistant, so that the password-encrypted key is vulnerable to a dictionary attack. For example, an adversary who compiled a dictionary of likely passwords steals the encrypted private key. (S)he decrypts a candidate key, signs an arbitrary message, and verifies it with a corresponding public key. (S)he repeats this procedure until (s)he gets a correct guess. Such attacks work in a relatively small space of passwords 1. This is the reason why we must take care when we handle the private key in a user-controlled environment. Lately several new methods were proposed to improve security of the passwordprotected private key in a user-controlled environment. They include the software smart card[7] and the networked cryptographic device[11]. They postulated a remote server and exploited network connectivity in a way to cooperate with the server for performing private key operations. So, an adversary had to compromise the server as well as the password-protected private key in order to steal user s private key in the end. The main difference between them was that the server was the only entity who can verify the signature in the former scheme, while the server assisted the device only in performing its private key operation in the latter scheme. They are notable and useful when we consider a practical solution for protecting user s private key in software rather than by using a tamper-resistant device. Both of them provided security claims clearly, so that it has been known they are secure simply under postulating the remote server. However, we have found a few weak points from them, respectively, in terms of security. For example, the software smart card was vulnerable to impersonation attacks in some practical cases[10]. This paper will scrutinize the networked cryptographic device in terms of security. The weak points may not be negligible for practical use in real world application and can be serious flaws in some sense. So, this paper will discuss the difficulty of protecting private keys in software and augment the networked cryptographic device with possible solutions. This paper is organized as follows: In Section 2 we will summarize basic notation and define a basic model that protects user s private key in software. In Section 3 we will describe the networked cryptographic device. Then we will scrutinize the weak points in Section 4 and augment the previous scheme with possible solutions in Section 5. Finally, Section 6 will conclude this paper. 2 Preliminaries In this section we describe notation to be used in this paper and define a basic model of protecting user s private key in software. 1 Password security has been studied for more than thirty years and there have been a great amount of work[13, 2, 6]. Recently the IEEE P1363 Standard Working Group is working on strong password protocols including SPEKE, SRP, PAK and AMP[8].

3 Entity User dvc svr adv On the Difficulty of Protecting Private Keys in Software 3 Functions - remembers π. - controls dvc. - types π into dvc. - holds the password-protected private key. - communicates with svr over a public network. - holds a private key. - communicates with dvc over a public network. - holds a dictionary of likely passwords. - controls the whole network. Table 1. Basic model of protecting private keys in software 2.1 Notation Let us borrow well-defined notation from [11]. Let κ be the main cryptographic security parameter such that κ = 160 while λ be a secondary security parameter for public keys, for example, λ = 1024 in that sense. Also we define a tiny parameter σ such that σ = 16. Here dvc and svr denote a user-controlled device and a remote server, respectively. Also π denote a user password while pk svr server s authentic public key and sk svr a corresponding private key. Here note that we will not describe in detail for public key operations of svr rather we will use E pksvr () and D sksvr () for convenience. However, we denote user s RSA public key pair as < e, N > and < d, N > where N is a good RSA product of two distinct odd primes, satisfying 2 λ 1 N < 2 λ, and e and d are, respectively, encryption and decryption exponents, satisfying e, d Zφ(N) and ed 1(mod φ(n))[17, 15]. The Euler totient function is denoted by φ(n). We will use h() to denote a strong one-way hash function while mac a () a specific type of keyed hash function, namely, a message authentication code (MAC). Also E b () and D b () will denote respectively encryption and decryption under a symmetric key b. A random padding is denoted by R() that will pad a pre-image with random bits to a multiple of the block length of encryption system, maintaining a record of the length of the pre-image. Finally C denote a X.509 certificate. Additional notation that was not described here, will be declared in each part of this paper. 2.2 Basic Model As we mentioned already, the networked cryptographic devices and the software smart cards respectively introduced valuable framework to protect user s private key in software[11, 7]. They postulated a remote server and exploited network connectivity in a way of cooperating with the server to perform private key operations for a user. We define a basic model of such schemes as shown in Table 1. In this model, an adversary adv is supposed to control any inputs to dvc and svr, hear all of their outputs, and attempt a dictionary attack. Also an adversarial goal may include recovery of the private key, signature forgery, and message decryption when we consider security of a private key.

4 4 T. Kwon 3 Protecting Private Keys in Software 3.1 Networked Cryptographic Device Networked cryptographic devices proposed lately by Phillip MacKenzie and Michael Reiter[11] are state-of-the-art in their provable approach of protecting user s private key by software-only techniques. Their scheme was inspired by the work of [5] and so is comparable with the cryptographic camouflage[7] in their similar goals. They do not require tamper-resistance of a storage device. Instead, they exploit network connectivity by postulating a remote server that assists the device in performing its private key operation. They assumed the remote server could be untrusted. They presented three kinds of protocols in their paper[11]. Among them we will handle two kinds of protocols such as a generic key retrieval protocol and a protocol for RSA signatures. Note the basic model we described in Section Generic Key Retrieval Protocol MacKenzie and Reiter presented a simple key retrieval protocol first. There are two phases such as device initialization and key retrieval for the generic key retrieval protocol of the networked cryptographic devices. Device Initialization. The inputs to device initialization are server s public key pk svr, user s password π, device s (actually user s) public key pk dvc, and its corresponding private key sk dvc. At device initialization time, the private key of the device is encrypted in a way that can be recovered only with the cooperation of both the device and the server. The device chooses v and a uniformly at random from {0, 1} κ, and computes b = h(π), c = f(v, π) sk dvc, and τ = E pksvr (< a, b, c >) where f() outputs a value of length equal to the length of sk dvc. The values v, a, τ, pk svr and pk dvc are saved in stable storage of the device while all the others must be deleted from the device. Key Retrieval. The device can run the following protocol with the server for retrieving the private key. Figure 1 depicts this protocol. 1. If a user types a password, the device computes β = h(π) and chooses ρ at random from {0, 1} λ. The device computes γ = E pksvr (< β, ρ >) and δ = mac a (< γ, τ >) where mac denotes a message authentication code. < γ, δ, τ > is sent to the server. 2. The server decrypts τ to get < a, b, c > and aborts if mac a (< γ, τ >) δ. The server decrypts γ and aborts if (β b). The server computes η = ρ c and sends this to the device. 3. The device computes ρ η f(v, π) to get sk dvc. If M(pk dvc, sk dvc ) 1, the device aborts where M() returns 1 for correct keys. Otherwise the device returns sk dvc. The next protocol does not recover the private key even to the user and provides an interesting feature such as key disabling.

5 On the Difficulty of Protecting Private Keys in Software 5 dvc β h(π) ρ R {0, 1} λ γ E pksvr (< β, ρ >) δ mac a(< γ, τ >) sk dvc ρ η f(v, π) abort if M(pk dvc, sk dvc ) 1 svr γ, δ, τ < a, b, c > Dsksvr(τ) abort if mac a(< γ, τ >) δ < β, ρ > D sksvr(γ) abort if (β b) η ρ c η Fig. 1. Generic key retrieval protocol 3.3 RSA Signature Protocol The RSA signature protocol provides an interesting ability for the user to disable a private key of the device even after an adversary has captured. For the purpose, the two-party RSA scheme is used in an additive manner, namely by splitting d into d 1 + d 2 [1, 11]. Disabling the private key was achieved by requesting that the server should permanently ignore the device s ticket. There are two phases such as device initialization and signature generation for the RSA signature protocol. Device Initialization. The inputs to device initialization are server s public key pk svr, user s password π, and device s (actually user s) public key pair such that pk dvc =< e, N > and sk dvc =< d, N > respectively. N is presumed to be a good RSA product of two distinct odd primes, satisfying 2 λ 1 N < 2 λ, and e and d are, respectively, encryption and decryption exponents, satisfying e, d Zφ(N) and ed 1(mod φ(n))[17, 15]. The Euler s totient function φ(n) must also be necessary. Then the device computes the followings: t R {0, 1} κ u h dsbl (t) v R {0, 1} κ a R {0, 1} κ b h(π) d 1 f(v, π) d 2 d d 1 mod φ(n) τ E pksvr (< a, b, u, d 2, N >) Finally the device saves the values t, v, a, τ, pk dvc and pk svr on its stable storage, and erases the other values such as u, b, d, d 1, d 2, φ(n), and π. Note that the values t and τ are backed up off line for key disabling features.

6 6 T. Kwon vrf dvc svr β h(π) ρ R {0, 1} λ r R {0, 1} κ sig γ E pksvr (m, r, β, ρ) δ mac a(γ, τ) γ, δ, τ < a, b, u, d2, N > D sksvr(τ) abort if mac a(γ, τ) δ < m, r, β, ρ > D sksvr(γ) abort if (β b) ν (enc(m, r)) d 2 mod N η ρ ν η ν ρ η d 1 f(v, π) s ν(enc(m, r)) d 1 mod N m 1 s e mod N m 2 enc(m, r) abort if m 1 m 2 verify C m 1 s e mod N m 2 enc(m, r) Abort if m 1 m 2 Otherwise, accept C, s, m, r Fig. 2. RSA signature protocol Signature Generation. The device can run the protocol depicted in Figure 2, in order to generate a RSA signature and send it to an actual verifier, vrf. In this method, the signature on a message m is defined as < s, r > such that s = (enc(m, r)) d mod N. The parameter κ sig denotes the number of random bits used in the encoding function enc(). Key Disabling. When the device was compromised, the user can send t and τ to the server so that the server records τ on a disabled list if h dsbl (t) u. 4 On the Difficulties In this section we scrutinize the weak points of the networked cryptographic device. 4.1 Adversaries An adversary is presumed to have a dictionary of likely passwords for the user and control the whole network, meaning that (s)he can control any inputs to the

7 On the Difficulty of Protecting Private Keys in Software 7 device dvc and the server svr, hear all of their outputs, and attempt a dictionary attack. Also (s)he can capture certain resources in the networked cryptographic device[11]. However, (s)he cannot succeed in breaking a RSA system since such a theoretical aspect is ignored simply by assuming that RSA is safe. Let us utilize the following definition for scrutinizing the weak points[11]. Definition 1. Adv(S) means the class of adversaries who succeeded in capturing S where S {dvc, svr, π}. It must satisfy Adv(S 1 ) Adv(S 2 ) if S 1 S 2. The networked cryptographic device was provably secure in meeting the security goals against the following adversary classes. Readers are referred to [11] for the details. Roman numerals denote each type of adversary classes. I. Adv({svr, π}) cannot forge signatures or decrypt messages. II. Adv({dvc}) needs on-line dictionary attacks. III. Adv({dvc, svr}) needs off-line dictionary attacks. IV. Adv({dvc, π}) can be frustrated by key disabling. However, we have found that some classes must be probed again, and the remaining classes must be observed as well. V. Adv({dvc, svr, π}) VI. Adv({π}) VII. Adv({svr}) VIII. Adv({}) As we can see from now, there were more adversarial classes to be observed on protecting private keys in software, and some of them were real threats. We will scrutinize them by each type of adversary classes. Class V. Firstly we define the following for observing Adv({dvc, svr, π}). Definition 2. An adversary in Adv(S) can totally break the system if S = {dvc, svr, π}. The total break means that either of the adversarial goals such as recovery of the private key, signature forgery, and message decryption, was achieved by an adversary in Adv(S). For example, an adversary in Adv({dvc, svr}) can totally break the system if (s)he succeeded in off-line dictionary attacks. All the other classes should not be derived to Adv({dvc, svr, π}) directly. 4.2 Capturing vs. Attaching By Definition 1, we claim that each class should not be transformed to a larger class without capturing the corresponding element explicitly. For example, it must be disallowed to derive Adv({dvc, svr, π}) from Adv({dvc, svr}) without capturing π or attaching Adv({π}) to the class explicitly. In this case, capturing π and attaching Adv({π}) can be slightly different from each other in their respective meanings. The former must have been done by an adversary in Adv({dvc, svr}), while the latter must have been derived from Adv({}).

8 8 T. Kwon Class VI. The only possible way of deriving Adv({π}) from Adv({}), could be the aspect of social engineering, for example, by threatening a human user. This is because an adversary in Adv({}) retains nothing for queries, assuming oracles. So, an adversary in Adv({dvc, svr, π}) can do presumably all the things an adversary in Adv({dvc, svr}) or Adv({π}) could do, while the adversary in Adv({dvc, svr}) or Adv({π}) cannot do the things the adversary in Adv({dvc, svr, π}) could do in some cases. Note that Adv({dvc, svr, π}) can be more powerful than Adv({dvc, svr}) in that sense. So, care must be taken when we consider adversarial classes. However, the social engineering aspect is an unavoidable threat when using a password, so that we neglect it technically in this paper as well. Here we define the followings for both capturing and attaching. Definition 3. Adv({S 1 } + S 2 ) means that a new element S 1 was captured by Adv({S 1 }), and is derived to Adv({S 1, S 2 }). Definition 4. Adv({S 1 })+Adv({S 2 }) means that a new class Adv({S 2 }) was attached to Adv({S 1 }), and is derived to Adv({S 1, S 2 }). For example, Adv({} + π) means that an adversary in Adv({}) has acquired π in a way of social engineering, while Adv({dvc, svr} + π) can imply ambiguously either case of social engineering or dictionary attacks for an adversary in Adv({dvc, svr}). However, by Definition 4, Adv({dvc, svr})+adv({π}) will denote social engineering for an adversary in Adv({dvc, svr}) while Adv({dvc, svr}+ π) dictionary attacks for the same adversary. Note that both can be derived to Adv({dvc, svr, π}), the total break! We summarize them where means derivation. Adv({}) Adv({} + π) Adv({π}) Adv({dvc, svr}) Adv({dvc, svr} + π) Adv({dvc, svr, π}) Adv({dvc, svr}) Adv({dvc, svr})+adv({π}) Adv({dvc, svr, π}) Similar cases can be observed in the other classes, such as Adv({dvc}) and Adv({svr}). So, we will scrutinize them and their threats in more detail. 4.3 Finding New Threats We will describe newly found threats on protecting private keys in software. For the purpose, two remaining classes must be observed such as Adv({svr}) and Adv({}). Class VII. Any adversary in Adv({svr}) has server s private key, sk svr, so that τ or γ can be decrypted by the adversary. Then, the adversary is able to find π by dictionary attacks on β or b. See Figure 1 and Figure 2 for the details. As a result, the following derivation is possible with a few queries. Adv({svr}) Adv({svr} + π) Adv({svr, π}) Adv({svr}) Adv({svr})+Adv({π}) Adv({svr, π})

9 On the Difficulty of Protecting Private Keys in Software 9 It must be a threat when we observe the following derivation. Adv({svr, π}) Adv({svr, π} + dvc) Adv({dvc, svr, π}) Adv({svr}) Adv({svr} + dvc) Adv({dvc, svr}) Simply if the device is captured, an adversary in Adv({svr, π} is more advantageous to total breaking than an adversary in Adv({svr}). So, class VII must be considered carefully to avoid such derivation. The possible threats are as follows. T1: The server can obtain password information by dictionary attacks, so that an adversary in Adv({svr}) can do the same thing. T2: In practice, the adversary in Adv({svr}) can deny services to the device. Class VIII. An adversary in Adv({}) can make the following derivation only. Adv({}) Adv({} + π) Adv({π}) It was derived in a way of social engineering, so that we can technically neglect it. However, the following threats can be observed for Adv({}) in practice. T3: An adversary in Adv({}) replays an old legitimate message to the server. Then, the replayed message can make a server busy without detection. T4: An adversary in Adv({}) generates a bogus message and sends it to the server. Then, the message can make a server busy without detection. The reason for T3 is that the server could not check any time-derived information from γ. Also the reason for T4 is that the device was able to generate τ at any time, even without communicating with the server[11]. For example, an adversary in Adv({}) generates a bogus message < γ, δ, τ > such that τ = E pksvr (< a, b, c >), γ = E pksvr (< b, ρ >), and δ = mac a (< γ, τ >). Then the server cannot decline the requested service when receiving the bogus message. Though the adversary cannot obtain the previously mentioned adversarial goals, (s)he can make the server busy enough to be in serious states. 4.4 Misunderstanding Adversaries We revisit the adversary classes of types I, II, and IV for more examination. Class I. Security against Adv({svr, π}) was proved in [11] in the random oracle model (See Theorem 6.1 and Theorem 6.2 in [11]). The following derivation is unavoidable to reach such a class. Adv({svr}) Adv({svr})+Adv({π}) Adv({svr, π}) However, the following derivation must be avoided as we mentioned with class VII (See T1 above). Adv({svr}) Adv({svr} + π) Adv({svr, π})

10 10 T. Kwon Class II. Security against Adv({dvc}) was achieved by detecting on-line attacks in [11]. Also off-line dictionary attacks were infeasible with overwhelming probability (See Theorem 6.3 and Theorem 7.3 in [11]). However, the following threat is observed. T5: An adversary in Adv({dvc}) sends t and τ to the server so that the user s private key is disabled. Class IV. Security against Adv({dvc, π}) was proved in [11] as well (See Theorem 7.4 in [11]). However, as we examined above, the only possible derivation to Adv({dvc, π}) is: Adv({dvc}) Adv({dvc})+Adv({π}) Adv({dvc, π}) As a result, it is of little importance to consider this class because there is no way better than social engineering in order to derive Adv({dvc, π}) from Adv({dvc}). Also it is obvious that an adversary in Adv({dvc, π}) can achieve the adversarial goals until the private key or the corresponding public key is disabled. 5 Augmentation In this section, we augment the networked cryptographic device against the weak points found in the previous section. The five threats are summarized as follows. T1: The server can obtain password information by dictionary attacks, so that an adversary in Adv({svr}) can do the same thing. T2: In practice, the adversary in Adv({svr}) can deny services to the device. T3: An adversary in Adv({}) replays an old legitimate message to the server. Then, the replayed message can make a server busy without detection. T4: An adversary in Adv({}) generates a bogus message and sends it to the server. Then, the message can make a server busy without detection. T5: An adversary in Adv({dvc}) sends t and τ to the server so that the user s private key is disabled. 5.1 Augmented Password Verification When verifying password information, the server decrypted τ and γ to compare β to b such that β = b = h(π). However, the values β and b did not have sufficient entropy, so that they were vulnerable to dictionary attacks[13, 2, 6]. So, we slightly modify the system to derive both values as follows. v R {0, 1} κ b h(v, π) β h(v, π) Such a modification will remove the possible threat, T1. Fortunately MacKenzie and Reiter corrected this as well in their newer paper on delegation[12].

11 On the Difficulty of Protecting Private Keys in Software Augmented Initialization with a Trusted Server When initializing the system, it was postulated that the device could initialize it alone, without communicating with the server. This property can be of interest but has critical weak points related many possible threats such as T2, T4, and T5. So, we need to modify the system to remove those threats. Let pks svr and sks svr denote server s signature key pair. Then the following must be abided by. The server must be trusted by the device, depending upon the server s authentic public key. The device and the server communicates with each other for initialization. The server signs b with sks svr for the following computation. D skssvr (b) means b and its corresponding signature α. We have to utilize the signature scheme for D skssvr (b), in which signature verification is much more efficient than signature generation, for example, the RSA signature scheme. τ E pksvr (< a, D skssvr (b), c >) The device removes t from its storage while the user must back it up off line. Then the threats, T4 and T5 can be removed. Note that T2 is unavoidable in any server-aided approaches[11]. However, postulating a trusted server is very important. 5.3 Including Time Stamps When an adversary replayed old legitimate messages, the server was not able to detect such replays and so had to be busy with processing them. We modify the system to include time stamps so as to reduce the possible threat, T3. Let ϕ denote a time stamp. Then the messages should include it as follows. ϕ δ mac a (γ, τ, ϕ) Finally, the server can verify ϕ when assisting the device with less computation, and request regeneration of the corresponding message if ϕ is out of the predefined range. Fortunately, MacKenzie and Reiter also seem to have found this threat and tried to correct it lately[12]. 5.4 Augmented Key Retrieval Protocol The augmented key retrieval protocol is as follows.

12 12 T. Kwon dvc β h(v, π) ρ R {0, 1} λ γ E pksvr (< β, ρ, ϕ >) δ mac a(< γ, τ, ϕ >) sk dvc ρ η f(v, π) abort if M(pk dvc, sk dvc ) 1 svr γ, δ, τ, ϕ < a, Dskssvr (b), c > D sksvr(τ) < b, α > E pkssvr (D skssvr (b)) abort if D skssvr (b) is incorret. abort if mac a(< γ, τ, ϕ >) δ abort if ϕ is out of range < β, ρ, ϕ > D sksvr(γ) abort if (β b) η ρ c η Fig. 3. Augmented key retrieval protocol Device Initialization. The device computes the followings. Note that the server must sign b in this stage. v R {0, 1} κ a R {0, 1} κ b h(v, π) c f(v, π) sk dvc τ E pksvr (< a, D skssvr (b), c >) The values v, a, τ, pk svr and pk dvc are saved in stable storage of the device while all the others must be deleted from the device. Key Retrieval. The device can run the augmented protocol with the server for retrieving the private key. Figure 3 depicts this protocol. 5.5 Augmented RSA Signature Protocol The augmented RSA signature protocol is as follows. Device Initialization. The device computes the followings. Also note that the server must sign b in this stage.

13 On the Difficulty of Protecting Private Keys in Software 13 vrf dvc svr β h(v, π) ρ R {0, 1} λ r R {0, 1} κ sig γ E pksvr (m, r, β, ρ, ϕ) δ mac a(γ, τ, ϕ) γ, δ, τ, ϕ < a, Dskssvr (b), u, d 2, N > D sksvr(τ) < b, α > E pkssvr (D skssvr (b)) abort if D skssvr (b) is incorret. abort if mac a(< γ, τ, ϕ >) δ abort if ϕ is out of range < m, r, β, ρ, ϕ > D sksvr(γ) abort if (β b) ν (enc(m, r)) d 2 mod N η ρ ν η ν ρ η d 1 f(v, π) s ν(enc(m, r)) d 1 mod N m 1 s e mod N m 2 enc(m, r) abort if m 1 m 2 verify C m 1 s e mod N m 2 enc(m, r) Abort if m 1 m 2 Otherwise, accept C, s, m, r Fig. 4. Augmented RSA signature protocol t R {0, 1} κ u h dsbl (t) v R {0, 1} κ a R {0, 1} κ b h(v, π) d 1 f(v, π) d 2 d d 1 mod φ(n) τ E pksvr (< a, D skssvr (b), u, d 2, N >) Finally the device saves the values v, a, τ, pk dvc and pk svr on its stable storage, and erases the other values such as t, u, b, d, d 1, d 2, φ(n), and π. Note that the values t and τ are backed up off line for key disabling features.

14 14 T. Kwon Signature Generation. The device can run the augmented protocol depicted in Figure 4, in order to generate a RSA signature and send it to an actual verifier, vrf. Key Disabling. When the device was compromised, the user can disable the private key by sending t and τ, while an adversary in Adv({dvc}) cannot achieve it. 6 Conclusion In our previous study, we found that the related work named the software smart card was vulnerable to impersonation attacks when we consider an interleaved session in some practical cases[7, 10]. So, in this paper, we made simple observation on the difficulty of protecting user s private key in software by scrutinizing the networked cryptographic device in details[11]. The networked cryptographic device was examined in terms of security and augmented by applying possible solutions. As we examined, it was difficult to protect the private key in software, even with provable security[11]. The private key management is important for securing user s digital identity in the cyber space. For the purpose, especially in a software-only environment, the networked cryptographic device may be useful with the proposed augmentation. When mobility is necessary for a user, simply we may deposit the passwordprotected private key to a trusted server under a careful management. In order to deposit and download the private key securely, much work have been done, for example, Perlman and Kaufman used a password-based key exchange protocol[14]. Similar methods were announced in a commercial field, for instance, Entrust s SPEKE roaming, RSA s virtual smart card[18], and so on. However, they are sensitive to a server compromise because all user credentials depend upon a centered server. For the reasons, multiple server approaches are of growing interest[1, 4, 9]. In that sense, the networked cryptographic device can deposit the encrypted private key and the related values to another trusted server for mobility. Two different servers could improve security compared to a single server approach. References 1. M. Bellare and R. Sandhu, The security of practical two-party RSA signature schemes, Manuscript, S. Bellovin and M. Merrit, Encrypted key exchange: Password-based protocols secure against dictionary attacks, In Proceedings of the IEEE Symposium on Security and Privacy, pp.72-84, S. Brands, Rethinking public key infrastructures and digital certificates, The MIT Press, p.11 and pp , 2000.

15 On the Difficulty of Protecting Private Keys in Software W. Ford and B. Kaliski, Server-assisted generation of a strong secret from a password, In Proceedings of the International Workshops on the Enabling Technologies: Infrastructure for Collaborative Enterprise, IEEE, June R. Ganesan, Yaksha: Augmenting Kerberos with public key cryptography, In Proceedings of the ISOC Network and Distributed System Security Symposium, February L. Gong, M. Lomas, R. Needham, and J. Saltzer, Protecting poorly chosen secrets from guessing attacks, IEEE Journal on Selected Areas in Communications, vol.11, no.5, pp , June D. Hoover, B. Kausik, Software smart cards via cryptographic camouflage, In Proceedings of the IEEE Symposium on Security and Privacy, 1999, 8. IEEE P1363.2, Standard Specifications for Public Key Cryptography: Passwordbased Techniques, May D. Jablon, Password authentication using multiple servers, LNCS 2020: Topics in Cryptology - CT-RSA 2001, Springer Verlag, pp , T. Kwon, Impersonation attacks on software-only two-factor authentication schemes, IEEE Communications Letters, Vol.6, Iss.8, August P. MacKenzie and M. Reiter, Networked cryptographic devices resilient to capture, In Proceedings of the IEEE Symposium on Security and Privacy, 2001, a full and updated version is DIMACS Technical Report , May P. MacKenzie, Personal Communications, August R. Morris and K. Thompson, Password security: a case history, Communications of the ACM, vol.22, no.11, pp , R. Perlman and C. Kaufman, Secure password-based protocol for downloading a private key, In Proceedings of the ISOC Network and Distributed System Security Symposium, February PKCS #1, RSA cryptography standard, RSA Laboratories Technical Note, Version 2.0, PKCS #5, Password-based encryption standard, RSA Laboratories Technical Note, Version 2.0, R. Rivest, A. Shamir, and L. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM, vol.21, pp , RSA Security Laboratories,