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.