A Multiple Kernel Learning Based Fusion Framework for Real-Time Multi-View Ac...
Report
1. BADA55 Curves for Compromising
Security Standards
Conor McMenamin
Final Year Project
B.Sc. Computational Thinking
Department of Computer Science
Maynooth University
Co. Kildare
Ireland
Supervisor: Dr. T. Dowling
Date: March 23, 2015
2. Acknowledgements
I would like to thank Dr. Tom Dowling for his encouragement throughout this project.
His helpful insight has had a very positive impact.
I would also like to thank my family for their contributions and unwavering support.
1
5. Abstract
This project is concerned with the existing standards for curve selection for Elliptic Curve
Cryptography. Specifically, how it is possible to manipulate and exploit these standards.
It will be shown that it is possible to produce curves which satisfy these standards but
which have an obvious characteristic chosen by the user. This characteristic has the
potential to make the curve more vulnerable to attack. The attack will be implemented
in Sage. The system will be thoroughly tested and conclusions and future work discussed.
6. Chapter 1
Glossary
Below are some of the most important abbreviations, and what they stand for, which are
used throughout the project.
CMD Complex Multiplicative Discriminant
CSPRNG Cryptographically Secure Pseudo-Random Number
Generator
DLP Discrete Log Problem
EC Elliptic Curve
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Helman
ECDLP Elliptic Curve Discrete Log Problem
1
7. Chapter 2
Elliptic Curve suitability for
Cryptography
2.1 Why use Elliptic Curves for Cryptography?
Since the beginning of society, cryptography has been present in one form or another.
As we have become more intelligent, and our access to computational power increases,
the standards by which we decide if something is secure must also adapt.
The best description of information being secure is the inability of unwanted indi-
viduals to have access to this information. Formally, many standards for ensuring the
security of cryptographic systems exist. However, these standards are not always conclu-
sive and many disagree on specific elements of most systems. These disagreements are
particularly numerous when it comes to new breeds of systems, and in particular, ECC.
The group structure of EC’s when defined over prime fields allows them to be used in
cryptography. However, the security behind ECC is based around the ECDLP[1], the
widely accepted infeasibility to find a number k that solves Q=kP, where Q and P are
points on some EC.
2
8. 2.2 Which Curves to use?
Measures have been taken to ensure curves chosen for use in ECC produce sufficiently
large search-spaces to deter would-be attackers. This has been formalized by the in-
troduction of standards. Some of the most popular implementations in current use are
Montgomery, Edwards and Menezes-Qu-Vanstone, to name but a few. An indepth knowl-
edge of EC theory and cryptography is needed to wade through the possibilities.
It is unanimously agreed upon that the standards enforce desirable properties in EC’s.
However, experts in the field, such as Dan Bersntein and Michael Scott[3][6], have time
and time again alluded to the potential existence of weaknesses in these standards. This
project aims to show the reader the extent to which individuals can manipulate these
standards.
2.3 Development of Standards
Some of the main standards for ECC include Certicom SEC 2 1.0 (2000)[12], IEEE Std
P1363 (2000)[11], ANSI X9.62[7], IEEE P1363[11], SEC 2[8], NIST FIPS 186-2[9] and
ANSI X9.63 (2001)[10], among others. The main standards focus on the hardness of the
ECDLP, and impose few curve-specific restrictions. Some of the standards include:
• NIST primes must be used to generate underlying fields.
• Curve coefficients must be ‘verifiably random’. This means they are hashes of
pseudo-random public seeds.
• The cofactor of a chosen Curve is less than 23
(some restrict this to 1).
• Any point P used in the ECDH protocol must have order equal to the largest prime
dividing the order of the curve.
An organization called ‘SafeCurves’[2] has been established to provide several addi-
tions to these standards. SafeCurves utilizes all of the strengths of the common stan-
3
9. dards, while also suggesting curve specific safety measures. Their main focus is on ‘twist
security’, a concept detailed in Chapter 3.
2.4 Questioning the Standards
This project investigates the situation where Malice, a malicious attacker, has secret
knowledge of a set of curves that can be chosen for use in ECC that have a publicly
unknown weakness which reduces the ECDLP to an easier domain.
This project is not trying to suggest such curves exist. To do this by showing an
actual vulnerability would be illegal. Instead, the user chosen parameter ‘BADA55’ is
substituted to demonstrate this concept by exhibiting the extent to which, within the
standards, it is possible for an attacker to exploit a weakness which occurs one in every
million, or even every billion, curves.
2.5 Organization
Chapter 3 covers some of the key concepts needed to understand the mechanics of ECC.
Chapter 4 outlines the requirements for the project. Chapter 5 implements a system to
manipulate the curve standards. Chapter 6 tests the system with several test cases used.
Chapter 7 gives the conclusion and outlines possible future work.
4
10. Chapter 3
Background
3.1 Mathematical Background
ECC relies on the group structure of EC’s over finite fields. A group G is a non-empty
set X with some binary operation * : X x X→ X , with * satisfying:
1. ∀x, y ∈ X, ∃z ∈ X such that x*y=z
2. ∀x, y, z ∈ X, (x*y)*z=x*(y*z)
3. ∃e ∈ X such that ∀x ∈ X , e*x=x*e=x (e is called the identity)
4. ∀x ∈ X, ∃ unique y ∈ X with x*y=y*x= e (y is called x’s inverse)
(In ECC, the group operation is addition of points on a curve).
The order of a group is the number of elements in the group.
The order of an element in a group is the smallest n greater than 0 such that
xn
= e (xn
= x ∗ x ∗ ... ∗ x n times).
A group X is abelian if x*y=y*x ∀x, y ∈ X. This property is by no means trivial,
and is important for the application of EC’s to cryptography.
A prime finite field, Fp, contains all elements from 0 to p-1 inclusive, with the
commutative operations addition, subtraction, multiplication and division all defined
5
11. (where division is not by 0).
The elliptic curves used in this project can be described algebraically by:
y2
= x3
+ ax + b
Here a and b are Real numbers, with (4a3
+ 27b2
) = 0. In ECC, a is generally set to
-3 for efficiency reasons[2], and b is restricted to integers in Fp. When defined over Fp
for some prime p, elliptic curves form an abelian group, denoted E(Fp), with identity
denoted O, representing a ‘point at infinity’, order denoted |E(Fp)| , and group operation
defined as follows:
Given two distinct points A=(x1, y1), B = (x2, y2) elements of a curve E, the operation
A*B=C, for some C=(x3, y3) on E is defined as:
x3 = (m2
− x1 − x2)mod p
y3 = (−y1 + m(x1 − x3))mod p
where m=(y1 − y2)/(x1 − x2).
Calculating A*A=C (we denote A*A as 2A, A*A*A as 3A, etc.), is done as follows:
x3 = (n2
− 2x1)mod p
y3 = (−y1 + n(x1 − x3))mod p
where n=(3x2
1 + a)/(2y1) , with y1 = 0, and a being the parameter a in our elliptic
curve.
The cofactor, h, is defined as |E(Fp)| /q , where q is the largest prime factor of
|E(Fp)|
The CMD of a curve E(Fp) is defined as: (t2
−4p)/(s2
) if (t2
−4p)/(s2
) ≡ 1 (mod 4),
or 4(t2
− 4p)/(s2
) otherwise, where t=p+1-|E(Fp)| , and s2
is the largest square dividing
t2
− 4p
A small subgroup attack is where an attacker sends some point Q on the curve
where Q has low order. The unknowing user sends back some multiple of Q, nQ. As Q
has low order, computing n is feasible and thus information is leaked. This is prevented
6
12. by ensuring the curve has a low cofactor.
A transfer, whether multiplicative or additive, converts the ECDLP into the simpler
Discrete Log Problem (DLP)[2].
The DLP involves the solving of ak
= b for k a positive integer, with a, b elements
of some group.
Every Elliptic curve has a quadratic twist[5], which maps the curve to an isomorphic
group. Isomorphisms between groups conserve group structure, and as such, every
operation in one group can be replicated in the other. If it were possible to map an
EC used in ECC into a group with easier operations, then the security behind the ECC
would crumble.
A twist secure curve is protected against a small subgroup attack in both the curve,
and it’s quadratic twist. A twist secure curve prevents this from happening by requiring:
• Cofactor of both the curve and the curve’s twist to be 1.
• Security level ≥ 2100
, ‘standard rho security level’[2].
• CMD ≥ 2100
[2].
3.2 Cryptographic Background
This project focuses on the use of elliptic curves in ECDH, a cryptographic key-exchange
protocol between two users who wish to establish a shared secret to generate a key with
which to communicate privately over an insecure channel. The protocol can be described
as follows:
Take two users, Alice and Bob, who wish to communicate privately. To do this they
need to agree on some secret key with which to encrypt/decrypt data. They both know
of some secure EC E, and some point P on the curve.
1. Alice chooses some integer in Fp, call it a. This is her private key.
7
13. Figure 3.1: A demonstration of the ECDH key exchange
2. Bob chooses another integer in Fp, say b. This is his private key.
3. Alice sends aP to Bob, who then sends bP to Alice.
4. Both users can now calculate abP, which is referred to as the session private key.
For an attacker, let’s say Malice, hoping to intercept and decipher messages from
the private conversation, she must first generate the shared secret used to encrypt and
decrypt the conversation. Assuming Malice is a proficient attacker, she will have access
to transferred messages, and thus will know E, P, aP and bP. Unfortunately for Malice,
it is unfeasible to generate abP from this information. To do this would require her to
break the ECDLP, an achievement which would have a seismic effect on civilization.
8
14. Chapter 4
Requirements
4.1 Introduction
The primary aim of this project is to investigate the possibility that ECC standards
can be manipulated by individuals. The following requirements were identified for this
project.
4.1.1 Software Requirements
For a reader attempting to implement any of the algorithms outlined in this project, the
following are recommended:
• Java Development Kit.
• IAIK JCE [15].
If these are unsuccessful, the following should be consulted:
• Sage Mathematics Software (Version 6.4.1)[4].
9
15. 4.1.2 Mathematical Requirements
Due to the complex nature of the algorithm a lot of mathematical knowledge is required.
In particular the following areas merit careful study;
1. Group Theory.
2. Elliptic Curve Theory, especially twists, cofactors, etc.
3. Ring and Field Theory.
4. Number Theory.
5. ECC.
The time required to develop competency in these key areas must be reflected in the
project plan.
4.1.3 Standards Requirements
It is a requirement to analyse and understand the standards of ECC [12] [11] [7] [8] [9]
[10]
4.1.4 Performance & Data Requirements
Not an issue, as the curves used in this project were generated off-line.
10
16. Chapter 5
Design
At this point, the reader should have an idea of the standards that dictate the choice of
curves for use in ECC. The next section focuses on taking these standards and developing
a system with which curves can be created that both pass the standards and have a
coefficient containing the string ‘BADA55’. A coefficient containing ‘BADA55’ does not
actually show that ECC is vulnerable. It does, however, show that it is possible to
implement a very structured and deliberate choice of curve. If someone were to know of
a weakness contained in ECC, then it would be just as straightforward to implement.
To do this, the first task was to come up with some tool to verify the validity of a
given curve. Initially, this was attempted in the IAIK JCE[15], see Prototype 1. The Sage
environment was then used to generate and test candidate curves based on Bernstein’s
work[3], see Prototype 2.
5.1 Prototype 1
A segment of code used in the IAIK ECDH protocol is given below:
final ECParameterSpec params = ECStandardizedParameterFactory
.getParametersByBitLength(keyLength);
To initialize an EC for use in this protocol, the user is only allowed to define one
11
17. which exists within the ‘ECStandardizedParameterFactory’ library. This immediately
restricted curve choice to a selection of standardized curve implementations. This project
was concerned with producing curves with user-defined parameters.
Thus, it was concluded that although IAIK may be useful for non-expert developers,
it did not support the research with which this project was concerned, due to it’s lack of
flexibility.
5.2 Prototype 2
The code below contains a series of checks, which if passed, verify that the curve which
is inputted is suitable for use in ECDH. The user is expected to input the coefficient B,
from the formula y2
= x3
− 3x + B and the prime p, determining the underlying field
Fp. It is assumed p is a NIST prime [14].
k = GF(p)
E = EllipticCurve([-3,k(B)])
n = E.cardinality()
print n != p
print n.is prime()
print (2*p+2-n).is prime()
print Integers(n)(p).multiplicative order() * 100 ≥ n − 1
print Integers(2*p+2-n)(p).multiplicative order() * 100 ≥ 2 ∗ p + 2 − n − 1
cmdisc = ((p+1-n)2
− 4 ∗ p).squarefree part()
if cmdisc % 4 != 1: cmdisc *= 4
print -cmdisc ≥ 2100
• The p here is a NIST prime[14] which is then used to define Fp, the field to be used
in the curve generation.
• E is then created to be the curve y2
= x3
− 3x + B in the field Fp.
• n contains the order of the curve E.
12
18. The next 6 ‘print’ statements are then standard checks:
1. The first checks if the order of the curve equals the order of the field. If this is the
case, it is possible to transfer E to the additive group Fp, where the DLP is much
easier to solve.
2. The second verifies that n is prime. This is equivalent to checking that the cofactor
is 1, which is required by most standards.
3. The third checks if 2p+2-n, from now on twist(n), is prime. This number, twist(n),
is the order of the twist of E. This check is specifically required by SafeCurves[2],
and is more stringent than the majority of other standards. Checking it’s primality
ensures the twisted group is also both large and robust (avoids small subgroup
attacks).
4. The fourth checks the multiplicative order of p mod n. SafeCurves requires this to
be at least (n-1)/100.
5. The fifth checks the multiplicative order of p mod twist(n). SafeCurves requires
this to be at least (twist(n)-1)/100.
6. The final check verifies that the complex multiplicative field discriminant, CMD,
referred to here as cmdisc, is greater than 2100
, for reasons alluded to earlier.
Note: The fourth and fifth checks are imposed as further verifications of security, both
in E, and its twist. Both of these checks prevent multiplicative transfers, which if allowed
to occur, would greatly reduce computation time for would-be attackers.
This provided a platform to choose curves at will and check their validity. The next
step was to implement some BADA55 curves.
13
19. Chapter 6
Implementation & Testing
6.1 Implementation
In this section, the algorithms discussed previously will be implemented on test data, with
results collected and observations made. The first test is the simplest implementation of a
BADA55 curve. Here it is assumed that the user is allowed to choose any parameters they
want. In the second it is then assumed that a ‘verifiably random’ restriction is in place.
SafeCurves[3] provides the result of a seed, which when hashed, produces a BADA55
coefficient. The final test demonstrates that it is possible to carry out an ECDH key
exchange using the curve described in the second test, with sample output given.
6.2 Testing
6.2.1 Non-Random Curve Choice
In this example B is obtained by iterating the parameter from the start string until an
acceptable curve is obtained. The resulting curve passes the relevant standards.
14
20. Purpose of Test Is it possible to implement a BADA55 curve?
Start String BADA55BADA55BADA55BADA55BADA55BADA
55BADA55BADA55BADA55BADA55BADA
B (in y2
= x3
− 3x + B) BADA55BADA55BADA55BADA55BADA55BADA
55BADA55BADA55BADA55BADA55BD48
p (in Fp) F1FD178C0B3AD58F10126DE8CE42435B3961ADBC
ABC8CA6DE8FCF353D86E9C03
Increments to B 623
Expected Result Pass
Actual Result Pass
Conclusion The BADA55 curve described by the B parameter given
passes all of the standard checks in Chapter 5
6.2.2 ‘Verifiably Random’ Curve Choice
In this example B is the result of cryptographically hashing the result of the 256 bit public
seed S. Cryptographic hashing is a non-invertible process which disrupts any underlying
properties of input by producing pseudo-random output. In this example, assuming the
hash function doesn’t change, hashing S will always produce B, verifying that B has gone
through the hashing process. This means B is ’verifiably random’, and as such, would
be accepted by all authorities if it passed the test below.
15
21. Purpose of Test Does EC with B parameter as described satisfy stan-
dards
S 3CC520E9434349DF680A8F4BCADDA648D693B29
07B216EE55CB4853DB68F9165
B (in y2
= x3
− 3x + B) BADA55ECFD9CA54C0738B8A6FB8CF4CCF84E9
16D83D6DA1B78B622351E11AB4E
p (in Fp) 2256
− 2224
+ 2192
+ 296
− 1
Expected Result Pass
Actual Result Pass
Conclusion The BADA55 curve described by the B parameter given
passes all of the standard checks outlined in Chapter 5
6.2.3 ECDH Key Agreement using BADA55-VR-256
Below is the information used in carrying out the ECDH Key Agreement Protocol be-
tween Alice and Bob, using the BADA55-VR-256 curve.
16
22. Purpose of Test Showing key agreement is possible using this curve
Curve BADA55-VR-256
Base Point, P (4, 138595662763951235054310379805407466138
7592575712877839693802679373516881326)
Alice’s Private Key, A 948605580195456209236845115994570041296
72807746172285874777212381343841280324
Bob’s Private Key, B 6779130039097623706301688206908090773297
7866666699896231858507684071917927556
Alice’s Public Key, AP (5609522417050706408233881164312218812889
0588316534999593883765272223936424632,
3977583095372839401987320082464826478364
4350603264348274670406816505827598178)
Bob’s Public Key, BP (1094513022159551643241573255360279182968
04671265434654695334716781305123410628,
7529230327072447690289015353130287313850
3809166508787625654052914797226644558)
Alice’s Secret A(BP) (2012103600886770837798904888724827326629
0576180160189984358876655280960471145,
1052790847985857545110195925358241838987
68771817678877180621064830212598978554)
Bob’s Secret B(AP) (2012103600886770837798904888724827326629
0576180160189984358876655280960471145,
1052790847985857545110195925358241838987
68771817678877180621064830212598978554)
Bob’s Secret == Alice’s Secret TRUE
Conclusion BADA55-VR-256 allows ECDH Key Exchange
Note: P is an arbitrary point on the curve. Any non-identity point will do for use
as the base point, due to the cofactor of the curve being 1 (see Chapter 5).
17
23. Chapter 7
Conclusion & Future Work
7.1 Conclusion
This project covered some of the cutting edge work on ECC, and why questions must
still be answered regarding its security. The aim of this project was to show how it
is possible to manipulate and exploit the standards for ECC curve selection. This was
done by describing the security behind EC’s and the standards which define them, and
then producing BADA55 curves that pass the standards, yet contain a structured and
deliberate characteristic chosen by the user.
7.2 Future Work
Interesting problems arose in this project and could form the basis for a future project.
These include:
• The work carried out to compute the ‘verifiably random’ curve in Chapter 6 is
omitted due to project restrictions. However, the process would involve generating
public seeds and hashing them until one produced a desired result. Searching
for this in anger would take a long time. However, applying some heuristic (i.e.
domain restriction) should greatly reduce the search time. This is not covered in
18
24. this project, but should be considered if pursuing this topic further.
• The cost of implementing an attack like the ones mentioned in this project is an
interesting topic and should be investigated. This cost involves both discovering a
weakness, and developing a method to exploit it in the wild, for the forces of good,
obviously.
• How are public seeds chosen for use in curve generation? It may be possible to
utilize a CSPRNG for generation of the public seed discussed in Chapter 3. The
public seed mentioned in many of the standards has no implementation specific
requirements. If CSPRNGs, e.g. Blum Blum Shub [16], were required, this may
reduce the capability of an attacker to generate specific curves.
19
26. Bibliography
[1] B. Schneier, Applied Cryptograpy, John Wiley and Sons, 1996.
[2] D. Bernstein & T. Lange, SafeCurves: choosing safe curves for elliptic-curve cryp-
tography. http: //safecurves.cr.yp.to (accessed March 23, 2015)
[3] D. Bernstein, How to manipulate curve standards: a white paper for the black hat,
2014. https://eprint.iacr.org/2014/571.pdf
[4] W. A. Stein et al., Sage Mathematics Software (Version 6.4.1). The Sage Develop-
ment Team, 2015. http://www. sagemath.org.
[5] L. Washington, Elliptic Curves: Number Theory and Cryptography, Second Edition
(Discret Mathematics and Its Applications). Taylor and Francis Group, 2008.
[6] M. Scott, Re:NIST announces set of Elliptic Curves, 1999. https://groups.
google.com/forum/message/raw?msg=sci.crypt/mFMukSsORmI/FpbHDQ6hM MJ.
[7] Accredited Standards Committee X9. American national standard X9.62-
1999 public key cryptography for the financial services industry: the ellip-
tic curve digital signature algorithm (ECDSA) , 1999. Preliminary draft at
http://grouper.ieee.org/groups/1363/Research/Other.html.
[8] Certicom Research. SEC 2: Recommended elliptic curve domain parameters, ver-
sion 2.0, 2010. http://www.secg. org/download/aid-784/sec2-v2.pdf.
21
27. [9] National Institute for Standards and Technology. Digital signature stan-
dard, 2000. Federal Information Processing Standards Publication 186-2
http://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2.pdf.
[10] Accredited Standards Committee X9. American national standard X9.63-
2001, public key cryptography for the financial services industry: key
agreement and key transport using elliptic curve cryptography, 2001.
http://grouper.ieee.org/group/1363/Research/Other.html.
[11] Institute of Electrical and Electronics Engineers. IEEE 1363-2000: Stan-
dard specifications for public key cryptography, 2000. Preliminary draft at
http://grouper.ieee.org/groups/1363/P1363/draft.html.
[12] Certicom Research. SEC 2: Recommended elliptic curve domain parameters, ver-
sion 1.0, 2000. http://www.secg. org/download/aid-386/sec2 final.pdf.
[13] Daniel J. Bernstein, Tung Chou, Chitchanok Chuengsatiansup, Andreas Hulsing,
Tanja Lange, Ruben Niederhagen, and Christine van Vredendaal. BADA55 elliptic
curves. http://safecurves.cr.yp.to/bada55.html (accessed March 23, 2015).
[14] NSA. Mathematical routines for the NIST prime elliptic curves, 2010.
https://www.nsa.gov/ia/ files/nist-routines.pdf (accessed March 23, 2015).
[15] Graz University of Technology, Secure Information and Communication Technol-
ogy. https://jce.iaik.tugraz.at/ (accessed March 23, 2015).
[16] P. Junod, Cryptographic Secure Pseudo-Random Bits Generation : The Blum-
Blum-Shub Generator, 1999 http://crypto.junod.info/bbs.pdf (accessed March 23,
2015).
22
