The Cryptographic Methods of the ABC-Protocol 2.0 By Jordan Hind for Kansas State University MSE Project 2006 Introduction The ABC-Protocol is an agent based cryptographic (ABC) protocol implemented in development libraries similar to Secure Socket Layer (SSL), but with a few additional features required for a highly paranoid agent environment. When used properly, they should allow for secure agent-toagent communications in both security agent environments (such as SIM type agent software) and in MANET type environments. The ABC-Protocol uses a variety of methods to ensure that secrecy and identity are within a high level of confidence. The exact requirements for these are defined in a formal requirements document included in with the project documentation. The ABC-Protocol is divided into three primary functions. The first is called the Session Layer, which establishes an encrypted channel for the rest of the functions to perform their tasks in secrecy. The second is the authentication channel which is used to ensure that any agent only communicates with other agents that share a common secret. The final layer is the data encryption layer, which is used to pass data or messages to hosts approved by the authentication layer. Session Layer Encryption An Elliptical Curve Diffie Hellman (ECDH) function is used to provide secrecy to the session layer, the layer that hides the protocol's following layers data. An ECDH function allows two parties to negotiate a secret key, known only to the two parties, based on a private value or private key that each party creates. Breaking the security of ECDH means computing the secret key without access to the private value (breaks where the private value is obtained are the fault of the protocol). An elliptical curve in cryptography is rarely an ellipse, but usually defined by a cubic equation [20]. Cryptography is used only when the elliptical curve is defined over a finite field (the author found it useful to think of this as similar to a discrete modulo field, the principle is relatively the same) F, often denoted GF for Galois Field. GF(p) indicates that the field is of size p, GF(p^m) is a field of size p^m. (explain the difference here ) The former is mostly used in cryptographic applications. To understand how the field is defined consider the first order equation y² = x³ + ax + b(mod p) with a and b being constants. All possible combinations of y and x are limited by the value of p. Now that the mathematics behind navigating the elliptical curve are understood, the Diffie Hellman exchange within the field of the EC is easy to grasp. With the assumption that the curve, E, is publicly known. A point on that curve, F, which is known to both agents (lets call them Agent A and Agent B) seeking to communicate. Agent A can pick a random number on the curve as their private key, lets call that Ak. This allows Agent A to compute Ak * F, which yields the agents public key which we will call AP. Agent B also does the same procedure for its respected variables. When Agent A now sends its public key to Agent B, who can calculate a secret key by multiplying its secret key by Agent A's public key. Agent A can also make the same calculation and arrive at the same secret key, using Agent B's public key instead. This is shown in the following equation. Bk * AP = Bk * ( Ak * F) = (Bk * Ak ) * F = Ak ( Bk * F ) = Ak * BP assume elliptical curve E is publicly known with the bounds GF(p) and p is publicly known Bk * AP = Bk * ( Ak * F) = (Bk * Ak ) * F = Ak ( Bk * F ) = Ak * BP Authentication Methods The ABC-Protocol uses a custom authentication based on a pre-shared secret, similar to the way IPSEC uses a pre-shared secret or similar to the way password authentication often works [14]. Certificates are not used as they both expand the scope of the project and due to the fact that Elliptical Curve cryptography is not used in certificates at the time of this creation. The superiority of elliptical curve cryptography was previously discussed, which makes it ideal for agent based communication. (Never the less, the architecture of the ABC-Protocol was designed in a way so that moving to a certificate based methodology would be easy.) The authentication process is based on the rigid interpretation of the cryptographic hash properties. If a cryptographic hash fails to hold these properties to be true, then the authentication is not trustworthy. These properties are as follows: a.) A cryptographic hash is a one way function. This means that the function cannot be reversed. No information about the input to a cryptographic hash can be determined from the output [6,16,18,20]. b.) A cryptographic hash should have a mapping of all possible inputs to all possible outputs. This mapping should be difficult, in a cryptographic sense, to duplicate so that two discrete inputs have the same mapping to an output [6,16,18,20]. The ABC-Protocol uses a hash as a distributed computation. Each host runs a hash on a list of values, one of which only hosts that are "trusted" have, and presents the value to the other host to prove its knowledge of the secret value only "trusted" hosts have. To prevent duplication or replay, each host runs the computation with a nonce the other host provided. As both hosts have all provided values, either host can run either side of the distributed computation to authenticate or check the other hosts value. This prevents the secret or trusted value from being transmitted or reused. If the properties of the hash listed above remain true, then the secret value cannot be recovered from the hash value being passed in transit [14,16]. In addition to the nonce values being random, the shared secret negotiated from the session layer is included in the authentication hash so that even if a nonce is not random no replay authentication can occur. After a host has successfully proven its identity (authenticated), it must then show that each following packet has originated unchanged from the authenticated host. This can be done with chains, such as a “Timed Efficient Stream Loss-tolerant Authentication” (TESLA) chains, which the author explored in CIS 825. Chains work by taking a hash of each outgoing packet in reverse order, so that when sent and received in regular order the next packet to arrive always verifies the previous packet. In the ABC-Protocol, a mechanism will be used called a Message Authentication Code or MAC. A MAC usually relies on a cryptographic hash of each packet concatenated with constants and a key (keyed-HASH MAC or HMAC, the most common MAC, is exactly this). A more advanced MAC is used in the ABC-Protocol where the MAC is integrated into the cipher's Mode [18]. This is discussed at length in the next section. The MAC that is integrated into the mode is called One-key MAC or OMAC [7,8]. OMAC doesn't use a hash, but instead uses a symmetric cipher in a mode that allows it to provide a similar service [12]. This mode is called CBC and can be briefly detailed in the next section, Data Encryption: Modes. Data Encryption The Data Encryption layer is secured by a symmetric block cipher and a key computed by each host involved in the process. A symmetrical clock cipher is a two way function that takes two inputs of defined lengths and has an output of a defined length. As a symmetric cipher is a two way function, the use of terms input and output depends on the direction of the cipher. A forward direction of the cipher is known as encrypting, while the reverse of this is known as decrypting. Encrypting is the process of turning the "plain text", the data to be protected, into cipher text, an unreadable scramble of the plaintext. Decrypting is the reverse of this process where cipher text is computed into plain text. This conversion process is dependent on a second input, regardless of the direction, called the key. A key may be considered a map between all possible inputs and all possible outputs. Without this key, an ideal symmetric cipher should produce cipher text that is indeterminate from random, so that without the best attempts at decrypting without they key are no better than random guesses [17,18]. Symmetric ciphers work through a variety of means usually including "xor", bit shifting and substitution. Contrary to popular belief, there are not a lot of mathematics in use in a symmetric cipher (although there are a lot of mathematics used in the construction and design of a symmetric cipher, especially in the selection of Substitution-boxes)[17]. The ABC-Protocol comes with a symmetric ciphers, Serpent. The specifics of the symmetric ciphers used in the ABC-Protocol will not be covered in this paper, for details on their inner workings consult the AES submission documents [1,2,15]. Serpent is chosen for this project because it’s the most secure cipher widely available [3, 18]. Only AES candidate ciphers were considered for their high amount of review, multiple implementations and mandatory documentation. Serpent is the primary and default cipher of the ABCProtocol, the addition of AES was made for resource limited devices (and everything about the protocol is designed with maximum paranoia, why stop at the cipher?) Data Encryption: Modes A block cipher is only as secure as the mode that its used in. A mode is a block cipher is used. The simplest example is the Electronic Code Book (ECB). ECB takes a block sized input and encrypts it with the key, after this another block sized input and encrypts it with the key and so on. If two inputs are identical then the cipher text created by ECB encryption will also be the same. A second example of a more advanced mode would be Cipher Block Chain (CBC) which takes the output of every block encrypted and XOR's it against the input of the next block to be encrypted. This prevents two identical inputs from having two identical outputs. It also makes deciphering a random encrypted block in a series of encrypted blocks difficult unless the previous encrypted block is known. A third mode that the user must be aware of to understand how the ABC-Protocol works is the counter mode (CTR). <fill in counter mode here> The ABC-Protocol uses a new mode called the EAX mode of operation (EAX is not an acronym although AE usually stands for Authenticated-Encrypted when discussing modes). EAX is a mechanism for combining a symmetric key mode with a packets MAC or tag (see the Authentication section of this document for more information on MAC) [7]. The MAC that EAX uses to combine with is OMAC mentioned previously. EAX is known as a two pass mode as it makes two passes over the data. One pass is to encrypt the data, the other pass is to run the cipher over the data in CBC mode, discarding the output of each blocks encryption execution except as input into the next blocks encryption execution. In this manner a final value can be reached (that is conveniently the same size as the cipher block) that represents the value of the data (and packets) in the same fashion as a hash [7]. The basic form of EAX is shown in the following diagram from [8]. This diagram shows inputs of a nonce (N), a message (M) and a header (H). The Nonce and the Header are run through the OMAC process with key K. The Nonce tag output of that is then fed into the CTR mode encryption process of the message M along with key k. The output of this is cipher text C, which is then processed with the OMAC and key K again. The output of this is then XOR’d with the OMAC output of the header H and the nonce N for a complete tag of T. The complete cipher text would be cipher text C with tag T appended to it [8]. Decryption of the packet is largely the operation following in reverse order beginning with a verification process that the packet received is at least the expected length of the tag. If not, then the packet can be discarded. Secondly an OMAC is taken of the nonce, header and cipher text, XOR’d against each other and then verified by comparison against the tag received. If the Tag value verified correctly, then the cipher text can be decrypted to reveal M, the original message [8]. The EAX Mode was modified slightly to avoid the problems with a MAC on Windows XP SP2 and above. Instead, a counter is started in place of the MAC field and OMAC’d into a hash value incrementing the counter as every packet leaves. This decouples the data from the packet, and tightly couples an order to which the cipher text packets arrive. It should be noted that while the counter field can be known and predicted, so is the header field and neither detracts from the security of the system. This modification is strengthened from the fact that the key used in the OMAC is tightly coupled into the authentication phase, and being able to compute the correct tag becomes dependant on the ability to complete the authentication phase (at least as strong as the other cryptographic properties used). The protocol also strengthens this mode modification by maintaining a running OMAC (OMAC total = OMAC(previous omac tag + incoming omac tag) of all the tag values is kept on both the sender and receiver. At the conclusion of a session the running tag from the sender is sent to the receiver as the FIN tag. If this value compares correctly to the receivers running tab (I believe any attack on this reduces to an attack on the cipher, except a trivial denial of service (keep sending invalid FIN packets)) then the receiver takes one more OMAC hash of that value, SHA256 hashes it and sends it back as a final FIN-ACK. The sender computes the same value and compares. Success of the functions is only returned if this process completes successfully. Without this last function, the modifications to EAX mode would be insecure (or at least less secure), therefor these modifications are only suitable for this protocol. This process has assured the receiver that the data is from the original sender by their knowledge of key K. It assures the receiver that the packet is un-tampered with by the MAC values of the header, nonce and cipher text [7,8]. And finally, because the ABC-Protocol uses an ephemeral key for the symmetric encryption that can only be computed by the host that authenticated, we are assured that the cipher text did indeed originate and was encrypted by the same host. Specific Requirement Handling In this section, mitigation explanations for each of the critical security requirements as detailed in the projects vision document will be shown. Ideally a proof should be shown to demonstrate the security of a protocol [19] and this was attempted. See the Architecture document for the ABCProtocol for details. Specific mis-requirements as detailed in the Vision document that were labeled as critical will be covered here with individual explanations of how the ABC-Protocol mitigates or satisfies them. Brute Force Key Search Description: A brute force key search is an attacker attempting to decrypt information from the channel by attempting decryption keys in a volume fashion until a correct key is found. This is the default attack of any cryptographic system and by deterring other attacks it is the hope to push attackers into brute force searches. This is a defining point in the security guarantee, meaning that an attacker must perform an exhaustive key search over the field of the key length. This is a security algorithm’s best case scenario and an attacker’s worst case scenario. The Brute for key search is not an attack that can never be completely mitigated. Instead, all phases of the protocol should be shown to withstand an acceptable amount of attack. An acceptable amount is in reference to the amount of time needed for an attacker, using modern equipment, to correctly determine the key by means of guessing. A standardized key strength of at least 128 bits in all phases of the protocol completes this requirement as by the NIST guidelines that should take until 2030 to break. Using Elliptical Curve keys of 256 bits, a random number generator with at least 128 bits of entropy, a hash with at least 128 bits of strength (SHA-256) and key lengths in the symmetric ciphers of 256 bits will fulfill this requirement in all phases. Eves Dropping Definition – Eves dropping is simply an attacker listening on the channel. Any information the attacker can harvest about the data or applications in the channel defines the attacker’s success. Specific Requirements – Eves Dropping on the ABC-Protocol channel should not reveal any information about the application layer within the limits of the security guarantee. Eves dropping should not be possible unless an attacker can guess or recover a private key from the ECDH key negotiation. This layer protects both the key negotiation which phase which an attacker would have to recover a key from to access the application data. In addition to this, an attacker would have to also be able to determine the shared secret key variable, even after they had broken the ECDH key negotiation. Man In The Middle Attack Description – A man in the middle attack is defined by an attacker performing a proxy service to data flows from both hosts, replacing security negotiation information with its own information on both sides of the channel. By placing themselves in the middle of every security negotiation the attacker gains necessary keys to learn something about the underlying data or applications. Specific Requirements – A “man in the middle” attack should not reveal any information about the application layer, and should not have greater likelihood of success than an exhaustive search of the authentication key space. The ABC-Protocol is resistant to Man-in-the-Middle attack because of its key creation through distributed computation process. With the assumption that a cipher holds its properties, no man in the middle attack would be successful because the attacker would not be able to recreate, reconstruct or decipher the symmetric encryption key as a shared secret value is never passed in the channel but is used as a variable in key creation. In addition, with the assumption that a hash (in this case SHA-256) holds its properties, the attacker cannot recreate the variables that were used in creation of the authentication value. Replay Attack Description – A replay attack is defined by an attacker recording a valid session and replaying the valid session against the receiving host at a later time. The receiving agent will accept the session data because the session is (was) valid in all respects. This is particularly damaging to agents receiving commands. Specific Requirements – No replay attacks should be successful with greater probability than a brute force attempt at the keys involved. For a simple replay attack to be successful the attacker is relying on both the ability to replicate the nonce’s and to reuse the ECDH keys as both are used as variables in the authentication computation, which will fail if the attacker is not correct with both values. The nonce is created from a PRNG with entropy of at least 128 bits ( and a length of 256 bits), which is not reused by definition of a nonce, so replaying this will not have a likely hood of success greater than brute force. Secondly, the public keys of the ECDH function are not reused and are also based on a PRNG with similar entropy, which also dissuades an attacker from a replay attack with greater probability than brute force. Impersonation Description – An impersonation attack is an attempt by a foreign agent to authenticate to an agent with invalid credentials. Special Requirements – No impersonation attack should be possible with greater probability than a brute force of the authentication key space. The authentication of the ABC-Protocol is based on a distributed computation, where each side of the agreement must arrive at an acceptable value. The computation used in the ABC-Protocol is a hash of values, including a secret shared value that is never passed. With the assumption that the oneway property of a hash holds true, this shared value cannot be recovered. With the assumption that the hash maps an input to one output not differentiated from random then the computation cannot be performed without the secret value with any probability more likely than brute force. References 1. Ross Anderson, et al. Serpent’s AES Submission Package and homepage. (A Candidate Block Cipher for Advanced Encryption Standard) http://www.cl.cam.ac.uk/~rja14/serpent.html 2. R. Anderson, E. Biham, L. Knudsen. Serpent: A Flexible Block Cipher with Maximum Assurance. AES Candidate Conference (AES1) 2000 3. R. Anderson, E. Biham and Lars Knudsen. The Case For Serpent. March 2000, Serpent homepage: http://www.cl.cam.ac.uk/~rja14/serpent.html 4. George Barwood. Elliptical Curve Cryptography FAQ. http://www.cryptoman.com/elliptic.htm Dec. 1997. 5. E. Barker, D. Johnson, M. Smid. Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography. NIST Special Publications 800-56A 6. M. Bellare, S. Goldwasser Lecture Notes on Cryptography 2004 MIT Summer Session Cryptography Short Course 7. M. Bellare, P. Rogaway and D. Wagner. A Conventional Authenticated-Encryption Mode. April 12, 2003. http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/eax/eax-spec.pdf 8. M. Bellare, P. Rogaway and D. Wagner. The EAX Mode of Operation (A Two-Pass Authenticated Encryption Scheme Optimized for Simplicity and Efficiency). Fast Software Encrption, 2004. http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf 9. W. Diffie and M. E. Hellman, New directions in cryptography, IEEE Transactions on Information Theory 22 (1976), 644-654 10. Damien Giry, Keylength.com (homepage) August 11, 2006 11. C. Hall, J. Kelsey, B. Schneier, D. Wagner. Cryptanalytic Attacks on Pseudorandom Number Generators. http://www.schneier.com/paper-prngs.html 12. Tetsu Iwata. OMAC: One-Key CBC MAC (homepage) http://www.nuee.nagoyau.ac.jp/labs/tiwata/omac/omac.html . University of Nagoya. May 1, 2006 13. Neal Koblitz. A Course in Number Theory and Cryptography (second edition). New York: Spinger Science+Business Media Inc, 1987. 14. L. Lamport Password Authentication with Insecure Communication 15. National Institute of Standards and Technology. Nist CryptoToolkit. http://csrc.nist.gov/CryptoToolkit/ 16. B Preneel, Analysis and Design of Cryptographic Hash Functions, PhD Thesis, Katholieke University of Leuven, 1993 (http://homes.esat.kuleuven.be/~preneel/phd_preneel_feb1993.pdf) 17. Bruce Schneier, Applied Cryptography. John Wiley and Sons Inc. 1996 18. Bruce Schneier, Niels Ferguson. Practical Cryptography. Indiana: Wiley Publishing, Inc. 2003 19. Shannon Communcation Theory of Secrecy Systems 1949 (http://www.cs.ucla.edu/~jkong/research/security/shannon1949.pdf) 20. William Stallings, Cryptography and Network Security. New Jersey: Prentice Hall, 1999.