外文翻譯---net compact framework嵌入式系統(tǒng)中的隨機(jī)控制協(xié)議（crp）

1、<p><b>　　翻譯部分</b></p><p><b>　　英文原文</b></p><p>　　Performance of the Controlled Randomness Protocol on .NET Compact Framework Embedded Systems</p><p>　　A

2、bstract—The Controlled Randomness Protocol (CRP) for management of cryptographic keys is a method to improve the security level of secure communication protocols. We assess the performance of the CRP when implemented on

3、embedded systems running the .NET Compact Framework. We present our findings from two different platforms: one smartphone running .NET Compact Framework 3.5 and one smartphone running .NET Compact Framework 4.0. Our asse

4、ssment verifies that when implemented in the .NET Compact F</p><p>　　I. INTRODUCTION</p><p>　　In real world applications of cryptographic protocols, the key management problem refers to the life

5、 cycle management of cryptographic keys. It includes the necessary operations for key generation; distribution; storage; replacement and exchange; usage; and destruction [1]. In order to retain a specific security level,

6、 keys used in cryptographic algorithms and protocols must be periodically refreshed i.e., new keys are exchanged between communicating parties and old keys are replaced. These prec</p><p>　　Key agreement is

7、the process by which two or more parties agree on a common cryptographic key for a specific timeframe. Key transport is the process by which the agreed key is transferred to the participants. In many scenarios, the two p

8、rocesses occur simultaneously: the participants exchange information by which they both set and exchange the key(s) to be used (or some parts of it). In many scenarios, the key agreement and transport occur as exchange o

9、f control messages through a control channe</p><p>　　In typical resource-limited environment, like the embedded systems are, it is rather costly to implement and use a publickey cryptography (PKC) scheme for

10、 secure communication between two entities. When the resource constraints are more severe or the participants are all known beforehand, another option is to replace the “heavy” PKC scheme in the control channel with a li

11、ghter SKC scheme. The SKC scheme can use a master key in order to set and transfer the ephemeral keys needed for the data chan</p><p>　　An embedded system can incur an interesting tradeoff on security level

12、and resource consumption. From a security point of view, the keys must be often refreshed, as explained earlier, in order to maintain the required security level. From a system resource consumption point of view, the key

13、s must be rarely changed, in order to minimize the consumption of precious resources (processor, power, bandwidth). Further, in some usage scenarios, advanced care must be taken in order to ensure that the new</p>

14、<p>　　The “controlled randomness protocol” (CRP) for cryptographic key management was proposed as an improvement for the security level of secure communication protocols [2]. The CRP allows multiple keys to be vali

15、d at any given time; it neither alters the total number of keys needed in the underlying cryptographic algorithms, nor the need of a control channel to periodically refresh keys. However, the increased security offered b

16、y CRP allows for far less frequent key exchanges. The Microsoft .NET Com</p><p>　　In this paper we assess the performance of the Controlled Randomness Protocol when implemented on embedded systems running .N

17、ET CF. We present our findings from two different embedded platforms: one smartphone running Microsoft Windows Mobile 6.5 with .NET CF 3.5 and one smartphone running Microsoft Windows Phone 7 with .NET CF 4.0. We also ve

18、rify our findings on a commodity desktop computer that supports the full .NET Framework 3.5. The performance reported in the latter environment is not cons</p><p>　　The rest of the paper is organized as foll

19、ows. Section II presents the key management problem and the controlled randomness protocol. Section III presents our testbed environment and experiments held. Section IV presents the results of our experiments and discus

20、ses our findings. Finally, Section V concludes our findings and discusses future directions of the work. </p><p>　　II. THE CONTROLLED RANDOMNESS PROTOCOL</p><p>　　Conventional cryptographic sche

21、mes operate under the assumption that at most one key is active in any time moment. There is only one exception to this assumption. This is the the transition periods when changing a cryptographic key. In these cases, at

22、 most two keys can be active in order to cope with delayed messages. Two of the authors of this paper proposed a novel approach of having more than one key at any given time moment [2]. The approach is based on the conce

23、pt of “controlled randomness”</p><p>　　Protocol Definition</p><p>　　Assume a time period t = [0, T] composed of time slots t1, t2, . . . , tn such as t = t1 ∪ t2 ∪ . . . ∪ tn. Each time slot ti

24、represents a session. Within each session one specific, temporal cryptographic key ki is used in conventional schemes. The Controlled Randomness Protocol works as follows. Within the time period t every cryptographic key

25、 k1, k2, . . . , kn is valid and can be used. The sender chooses with a uniform distribution a random integer i and encrypts the input data using the key </p><p>　　and thus, use the correct one to decrypt th

26、e ciphertext. The CRP does not dictate how all these keys are transferred to the receiver. It can be through a control channel using a PKC scheme, or an SKC with master key, or any other method. The CRP dictates how all

27、these keys are used and reused within a time frame composed of many conventional sessions.</p><p>　　Two different methods are originally proposed in [2] for deriving the index, j, of the secret key used for

28、a given ciphertext. The first method is using a synchronized random number generator (RNG) in both the sender and the receiverfor the indexes.</p><p>　　The second method involves usage of a Keyed Hash Functi

29、on(KHF) also known as Message Authentication Code(MAC). The sender and the receiver agree on a set of n encryption keys for a chosen encryption algorithm as usual and additionally on a set of n keys for computing MAC. Th

30、e sender further uses an RNG. In this cases, the sender works as follows for every plaintext m:</p><p>　　1) Sender chooses a random number j.</p><p>　　2) Sender encrypts m under key kj to produc

31、e the ciphertext E(m, kj).</p><p>　　3) Sender computes H(E(m, kj), hj) i.e., the MAC of the ciphertext using the j-th MAC key.</p><p>　　4) Sender sends E(m, kj)||H(E(m, kj), hj), where || denote

32、s the concatenation operation.</p><p>　　The receiver works as follows to recover m from the quantity E(m, kj)||H(E(m, kj), hj):</p><p>　　1) Receiver computes H(E(m, kj), hj) for every possible j

33、 = 1, 2, . . . , n. This step involves at most n MAC operations. Upon completing all computations, the receiver has derived the secret index j used by the sender.</p><p>　　2) Receiver decrypts E(m, kj) using

34、 the j-th decryption key. This step involves one decryption operation and derives the plaintext m.</p><p>　　B. Advantages of CRP</p><p>　　The concept of controlled randomness i.e., having multip

35、le active keys at any given time moment, offers superior security characteristics compared to conventional protocols. The system designer can reuse well-known cryptographic blocks in an novel way to achieve increased sec

36、urity with minimal hassle:</p><p>　　? minimal computational effort can be induced by CRP in the case that both sender and receiver can maintain a synchronized random number generator.</p><p>　　?

37、 the synchronization requirement can be relaxed, if the system can sustain some increased computational effort induced by the KHF (MAC) operations.</p><p>　　? in heavily constrained environments, the two abo

38、ve mechanisms can be replaced by sending the random number j with each packet. In this case, some security is indeed sacrificed since an attacker can know which packet is encrypted under what key. Yet, the intermix of ke

39、ys allows consecutive packets to be encrypted under different keys and thus, protect against some cryptanalysis attacks.</p><p>　　The CRP allows in all above scenarios to extend the lifetime of each key way

40、beyond the time of a conventional session. Further, it allows less frequent exchanges of messages in the control channel (if one is implemented), since less keys are needed to achieve a specific security level for a spec

41、ific timeframe. An attack on the classical key management protocol with a master key of n bits has complexity O(22n/3); an attack on the RNG for the controlled randomness protocol with _ keys has complex</p><p

42、>　　Problem statement</p><p>　　It is argued that the KHF (MAC) method leads to an efficient implementation in the case of combining a symmetric encryption algorithm with KHF operations, since the latter ar

43、e an order of magnitude faster than the former [2]. This assumption holds if the MAC algorithm is implemented based on a hash algorithm rather than on a symmetric key algorithm. In the simplest scenario, a 0.05_ overhead

44、 is introduced on average for superior security. In a more complex scenario, this overhead can be lowered</p><p>　　III. METHODOLOGY</p><p>　　Protocol implementation on .NET Frameworks</p>

45、<p>　　We implemented the classical protocols and the two methods of controlled randomness. The protocol implementation simulates a session of data where n keys are used in total for the three key management varian

46、ts (classical, CRP with synchronized random number generation, and CRP with keyedhash function).</p><p>　　We used as the underlying symmetric key encryption method the AES algorithm which is readily availabl

47、e in both Compact Frameworks (3.5 and 4.0). The .NET Compact Framework up to version 3.5 does not offer an implementation of a MAC algorithm. Thus, we implemented a MAC algorithm</p><p>　　that is based on th

48、e SHA1 hash function. The .NET CF 4.0 offers an HMAC implementation based on the SHA1 algorithm.</p><p>　　For sake of completeness and comparison, we also implemented the three protocols in the .NET Framewor

49、k 3.5 for a desktop computer.</p><p><b>　　Testbed </b></p><p>　　Our testbed consists of four platforms. The first one is the Windows Mobile emulator (Microsoft Visual Studio 2008 wit

50、h Windows Mobile SDK). The emulator can emulate Windows Mobile 6.0 and 6.5 devices. The second one is a consumer device, an HTC Touch Pro smartphone. The smartphone runs a stock version of the operating system with .NET

51、Compact Framework 3.5. The third one is the Windows Phone 7 emulator (Microsoft Visual Studio 2010 Express for Windows Phone with Windows Phone SDK). The emulator</p><p>　　Finally, we used a PC running Micro

52、soft Windows 7 with .NET Framework 3.5 as a reference platform for validating our findings and checking for any differences between the .NET Framework and .NET Compact Framework implementations.</p><p>　　C.

53、Experiments</p><p>　　We run sets of experiments for release versions of the code, for Desktop, Windows Mobile 6.5 Professional (on emulator and real device), Windows Phone 7 (on emulator). In total, there ar

54、e four (4) different setups to test. We did not carry real-world experiments for Windows Phone 7, due to lack of real devices by the time these experiments took place. We run two sets of experiments in all platforms. The

55、 first set relates to the performance of the CRP depending on the number of keys used. </p><p>　　We run experiments for 4, 8, 16, and 32 keys. We opted to limit the experiments up to 32 keys since it already

56、 offers a superior level of security and keeps the average processing overhead relatively low.</p><p>　　The second set relates to the performance of the CRP depending on input size. We run experiments for 32

57、, 64, 128, and 256 KB. We opted not to validate for larger sizes given the constrained nature of the device. One should not realistically expect to exchange larger packets with such devices.</p><p>　　IV. RES

58、ULTS AND DISCUSSION</p><p>　　All measurements reported are the average time of 100 protocol executions for the .NET Compact Framework (3.5 and 4.0) and of 1,000 protocol executions for the .NET Framework 3.5

59、. The mean times are in milliseconds. The execution time was measured using the System.TickCount API call, which offers millisecond granularity. The standard deviation was almost zero in all cases. This is an expected ou

60、tcome, since the Windows Mobile operating system runs only one process each time. Thus, the execution </p><p>　　A. Results for .NET Compact Framework 3.5</p><p>　　We report in Table I the result

61、s for the .NET Compact Framework 3.5 on Windows Mobile 6.5. The experiments ran both on emulator and on a real device. No significant difference was observed in the two sets of measurements.</p><p>　　A first

62、 finding is that the implementation of the AES algorithm in the .NET CF 3.5 platform is extremely slow. This finding is consistent across all packet sizes and number of keys used. We also verified this in the initial ben

63、chmarks we ran for comparing AES with SHA1 implementation. Probably, AES implementation must be revised on this platform. </p><p>　　The CRP/RNG implementation offers comparable performance with classical pro

64、tocols for key management, although the latter do not utilize multiple keys per session. This is an expected behavior, since, from an implementation point of view, CRP/RNG adds only the use of a random number generator.&

65、lt;/p><p>　　The CRP/HMAC implementation for the simple scenario (one HMAC per each packet) increases the required computational effort by a linear factor to both the packet size and the number of keys. The incr

66、ease is between 10% (in case of 4 keys) and 80% (in case of 32 keys). When CRP/HMAC is implemented on the more complex scenario (one HMAC per n packets), the overheads are lowered, as expected, and within 1-20% range (n

67、= 4 : 3.5 ? 20%, n = 8 : 2 ? 15%,and n = 16 : 0.7 ? 7%).</p><p>　　We note that it is up to the system designers to decide if, as the number of keys increases, this overhead is acceptable or to opt for fewer

68、keys, without a big sacrifice in the achieved security level. The work for an eavesdropping attacker is smaller but remains exponential to both the symmetric key and the MAC key size, as described in Section II.</p>

69、;<p>　　B. Results for .NET Compact Framework 4.0</p><p>　　We report in Table II the results for the .NET Compact Framework 4.0 on Windows Phone 7.0. The experiments ran on emulator only. </p>&

70、lt;p>　　The performance on the emulator for the .NET CF 4.0 is rather improved compared to that of .NET CF 3.5. All protocols now execute ten to twenty times faster. This improvement depends solely on the faster AES im

71、plementation. However, it is necessary to verify these findings on a real device, once it becomes available. It might be the case that the current version of the emulator contains an implementation of the algorithm that

72、will not be incorporated in the final product.</p><p>　　Initial benchmarking showed that the SHA-1 implementation on .NET CF 4.0 is slower than the SHA1 implementation on the .NET CF 3.5. The faster AES impl

73、ementation combined with the slower HMAC algorithm results in larger overheads. This is because the performance of the two algorithms does not differ by an order of magnitude any more. We can now see overheads three to s

74、ix times bigger than before on the same setup. As an example, consider the case of packet size of 64 KB with 32 keys: on .NET CF </p><p>　　As long as the results are further verified in a real device, the sy

75、stem designers should use the minimum acceptable number of keys as to minimize the induced computation overhead and retain a high level of security. </p><p>　　C. Results for .NET Framework 3.5</p><

76、;p>　　We report in Table III the results for the .NET Framework 3.5 on a desktop computer running Microsoft Windows 7 32- bit. Our findings on the desktop platform are quite similar with those reported in [3]. However,

77、 they are quite different on AES compared to the .NET CF 3.5. The performance deviation of AES in .NET CF 3.5 compared to .NET Framework 3.5 indicates that the two frameworks probably incorporate different implementation

78、s of the algorithm.</p><p>　　The computational overhead for CRP/HMAC is increasing by a linear factor to both the packet size and the number of keys. However, in absolute numbers, it remains within acceptabl

79、e ranges. Thus, a system designer can opt for a larger number of keys as to achieve a very high level of security.</p><p>　　V. CONCLUSIONS AND FUTURE WORK</p><p>　　In this paper we assessed the

80、performance of the controlled randomness protocol when implemented in the .NET Compact Framework 3.5 and 4.0. Our findings validate the claims of the initial protocol proposal: the overhead on the encryption side is prac

81、tically non-existent and only a small, tolerable processing overhead can be induced in the decryption side, despite the increased number of required computations. Thus, the controlled randomness protocol can be a viable

82、implementation option in embed</p><p>　　A reference implementation on a commodity desktop revealed quite different performance figures for the two platforms (.NET Compact Framework 3.5 and .NET Framework 3.5

83、). However, the desktop performance is in line with this published literature. It is an indication that the two platforms incorporate different implementations of cryptography, while sharing a large portion of other code

84、 and being akin.</p><p>　　In the future, we would like to extend the work and compare with other cross-platform libraries, like a Java-based implementation. It is also interesting to validate our findings on

85、 the final version of Windows Phone 7 and on an actual device, once such a device is available. Another option is to extend our work on Google Android, Nokia Meemo, and possibly other similar devices.</p><p>

86、;　　ACKNOWLEDGEMENTS</p><p>　　Dr. A.G. Voyiatzis and Prof. D.N. Serpanos were supported by the EU project INTERMEDIA (38419), in the frame of the EU IST FP6 Programme.</p><p>　　REFERENCES</p&g

87、t;<p>　　[1] Jan C.A. Van Der Lubbe, Basic Methods of Cryptography. Cambridge University Press, 1998.</p><p>　　[2] D. N. Serpanos and A. G. Voyiatzis, “Increasing symmetric key lifetime by controlled r

88、andomness,” in Emerging Technologies and Factory Automation, 2005. ETFA 2005. 10th IEEE Conference on, vol. 2, Sept. 2005, pp. 575–580.</p><p>　　[3] G. A. Francia and R. R. Francia, “An Empirical Study on th

89、e Performance of Java/.NET Cryptographic APIs,” Information Security Journal: A Global Perspective, vol. 16, no. 6, pp. 344–354, 2007.</p><p><b>　　表格1：</b></p><p><b>　　表格2：<

90、/b></p><p><b>　　表格3：</b></p><p><b>　　中文譯文</b></p><p>　　.NET Compact Framework嵌入式系統(tǒng)中的隨機(jī)控制協(xié)議（CRP）性能</p><p>　　摘要——用來進(jìn)行密鑰管理的隨機(jī)控制協(xié)議（CRP）是提高安全通信協(xié)議的

91、安全級(jí)別的一個(gè)方法。CRP用于驅(qū)動(dòng).NET Compact Framework的嵌入式系統(tǒng)中，我們以此來評(píng)估其性能。我們用兩個(gè)不同的平臺(tái)來支持我們的發(fā)現(xiàn)：基于.NET Compact Framework 3.5的智能手機(jī)和基于.NET Compact Framework 4.0的智能手機(jī)。</p><p>　　我們的評(píng)估證明，當(dāng)CRP在.NET Compact Framework中執(zhí)行時(shí)，它不僅在常規(guī)的密鑰管理協(xié)

92、議的基礎(chǔ)上進(jìn)一步提高了安全性，同時(shí)加上了開銷配置和耐受量計(jì)算。</p><p><b>　　一 總體介紹</b></p><p>　　在現(xiàn)實(shí)世界加密協(xié)議的應(yīng)用中，密鑰管理問題指的是加密密鑰的生命周期管理。它包括了密鑰的生成、分配、存儲(chǔ)、替換和交換、使用和銷毀等必要操作[1]。為了保持一個(gè)特定的安全級(jí)別，用于加密算法和協(xié)議的密鑰必須定期更新，即在通信雙方用新密鑰取代舊

93、密鑰進(jìn)行交流。這些預(yù)防措施確保了只有特定數(shù)量的信息是用相同密鑰加密的，因此，即使是密鑰泄露，能夠被破解的信息也達(dá)到了最小值。</p><p>　　密鑰協(xié)商就是兩方或兩方以上在一個(gè)常規(guī)的特殊時(shí)刻表加密密鑰上達(dá)成一致的過程。密鑰傳輸就是協(xié)商好的密鑰被傳送給參與者的過程。在許多案例中，兩個(gè)過程同時(shí)發(fā)生：參與者們在交換信息的同時(shí)也設(shè)置和交換了要使用的密鑰（或者其中的一部分）。在許多案例中，密鑰協(xié)商和傳輸作為控制信息通過控

94、制信道進(jìn)行交換。這個(gè)信道并不干擾進(jìn)行安全數(shù)據(jù)交換的數(shù)據(jù)信道。公鑰密碼體制（PKC）常用于控制信道，以進(jìn)行安全的交流；對(duì)稱密鑰密碼體制加密/解密用于數(shù)據(jù)信道內(nèi)的數(shù)據(jù)的安全傳輸。后者通常被稱作短暫密鑰或者回話密鑰，因?yàn)樗鼈冎淮嬖谝粋€(gè)特殊的時(shí)段，換言之，當(dāng)會(huì)話完成后，它們就被處理掉了。</p><p>　　在典型的資源有限的環(huán)境中，例如嵌入式系統(tǒng)，實(shí)施和使用公鑰加密（ＰＫＣ）方案來進(jìn)行兩個(gè)實(shí)體之間的安全交流是十分昂貴的

95、。當(dāng)資源嚴(yán)重受限或者參與者事先被知曉時(shí)，可以用相對(duì)“便宜”的SKC方案來替代控制信道中“昂貴”的PKC。SKC方案可以使用一個(gè)主密鑰來設(shè)置和調(diào)用數(shù)據(jù)信道所需的短暫密鑰。為了節(jié)約資源，相同的ＳＫＣ算法可以被分別用于控制和數(shù)據(jù)信道中，當(dāng)然是通過不同的密鑰通道。</p><p>　　嵌入式系統(tǒng)可以在安全水平和資源消耗之間達(dá)到有趣的平衡。從安全的角度來看，密鑰必須經(jīng)常刷新，以保持所需的安全級(jí)別，如前所述。但是從系統(tǒng)資源消

96、耗的角度來看，密鑰必須很少改變，以盡量減少珍貴資源（處理器、電源、帶寬）的消耗。此外，在一些使用過程中，必須采取先進(jìn)的管理，以確保新的密鑰在必要的時(shí)候是可用的，尤其是當(dāng)只存在間歇性連接時(shí)。</p><p>　　加密密鑰管理中的“隨機(jī)控制協(xié)議（ＣＲＰ）”的提出被認(rèn)為是安全通信協(xié)議中安全水平的一大提高[2]。CRP允許在特定時(shí)間內(nèi)多個(gè)密鑰有效；它既不需要改變底層加密算法所需的密鑰的總數(shù)，也不需要在控制信道中定期刷新密

97、鑰。然而，CRP產(chǎn)生的加強(qiáng)了的安全性卻限制了密鑰交換的頻率。</p><p>　　微軟的.NET Compact Framework (.NET CF)是一款基于微軟Windows CE平臺(tái)的軟件框架，在手機(jī)和嵌入式系設(shè)備中運(yùn)行。這些設(shè)備包括智能手機(jī)、掌上電腦和工廠控制器。.NET CF使用完整的.NET Framework的庫的一個(gè)可利用的子集。它還包括一些額外的、移動(dòng)設(shè)備特定的庫。.NET CF庫實(shí)際上是完整

98、的.NET Framework的庫的精簡版本，以便盡量減少它們的占位面積并適應(yīng)手機(jī)和嵌入式設(shè)備中有限的資源環(huán)境。</p><p>　　在本文中，我們評(píng)估.NET CF嵌入式系統(tǒng)運(yùn)行時(shí)ＣＲＰ的性能。我們從兩個(gè)不同的嵌入式平臺(tái)上提出我們的研究結(jié)果：一個(gè)是使用.NET CF 3.5的Microsoft　Windows Mobile 6.5操作平臺(tái)的智能手機(jī)；另一個(gè)是使用.NET CF 4.0的Microsoft Win