The CAMP SCMS uses some cryptographic techniques that are not in widespread use in other PKIs. This section provides relevant cryptographic background. In the subsection Crypto Primitives affecting End-Entity, we point out the primitives that also affect EEs.
Notation
To understand the special cryptographic constructions in this section, it is necessary to understand some of the underlying mathematics first. In the Elliptic Curve Cryptography system, the objects of interest are “elliptic curve points” which have the form (x, y) where (x, y) are all the points that are solutions of a particular cubic equation. A point P can be scalar-multiplied by an integer, a (a-times repeated addition of P by itself), to get a new point Q = aP. (Upper-case letters are used to indicate points, lower-case to indicate integers). In this coherence, multiplication of a point by an integer is defined so that it follows typical mathematical rules and always generates another point on the curve. The Elliptic Curve Discrete Logarithm Problem is basically the statement:
Given P and Q = aP, but not a, it is very difficult to work out the value of a.
In the following, for a, an element of {0, 1} and an integer b, ab denotes a b-bit string of a's (e.g., 064 is a 64-bit string of 0's); for bit strings c and d, c XOR d denotes their exclusive-OR; for bit strings x and y, x || y denotes their concatenation; and for a bit string Z and an integer n, [Z]n denotes n most significant bits of Z. For a key k and message m, AES(k, m) means AES encryption of m with k in ECB mode. In addition, unless otherwise noted, l is the order of the elliptic curve, la_id1 and la_id2 are 16-bit identifiers of linkage authorities LA1 and LA2, respectively, i, j, and k are 32-bit strings, and for brevity (i, j) are sometimes denoted by ι (Greek letter iota).
Time Periods
- Cryptographic primitives explained in the sub-pages including SCP1: Butterfly Keys and SCP2: Linkage Values generate a sequence of cryptographic values. In other words, both techniques use functions that map from a known sequence (such as 1, 2, 3, …) to a sequence whose entries are a priori unknown and unpredictable. The cryptographic details of the functions do not depend on the exact form of the input sequence, so one natural way they could be defined would be for the input sequence to be a single counter i = {0, 1, 2, 3, …}. In practice, in this document, two different approaches to define the techniques are employed. When defining the techniques for purposes of explaining the core concept, the techniques are written as if they take an input defined by a single counter ι. This is the Greek letter iota.
- For purposes of implementation, the input will be defined by two values, i and j. These are related to the pseudonym certificate provisioning model described in Use Case 3: OBE Pseudonym Certificates Provisioning. This use case utilizes a coarse time period with a counter i and a more granular counter j, which is reset to 0 at the start of each i-period.
Note that i and j uniquely define ι, an exemplary bijective. The term bijective is a mathematical term describing the characteristics of a function. A bijective function is both injective and surjective and implies a unique one-to-one relationship between the inputs and outputs of the function. When i and j are used for the input sequence, it is assumed that all devices and all SCMS components use the same value of i to denote the same time slot. In other words, i is a globally assigned variable, not a variable that individual OBEs or RAs have the ability to choose at will.
Pseudonym Certificate Validity
The length of the i-period should be the number of minutes in a week, 10080. We need to express it in minutes (as opposed to seconds) because the encoding in 1609.2 lets us use quantities of up to 216 units and there are more than 216 seconds in a week. The lifetime of the certificate is the i-period plus an overlap period. In the old design, the overlap period is one minute, but there are safety concerns with such a small overlap period, so we are extending the overlap period to one hour. This will enable vehicles to postpone certificate change if they are in an alert state that lasts more than a minute. With this extended overlap period, the lifetime of a pseudonym certificate is 10140 minutes.
The start validity time of a pseudonym certificate is given in seconds since the 1609.2 epoch of 00:00:00 UTC, January 1, 2004.
If leap seconds happen, we may choose to adjust the start validity time of the certificates so it is not always 60*10080 seconds after the start of the previous batch but instead always lines up with the top of the hour. This concern is out of scope for POC and will be addressed later.
Clock Time Corresponding to global i=0
For the Safety Pilot, the clock time corresponding to i=0 was defined to be 00:00 UTC January 1, 2010. However, a lot has changed since, and in particular, the meanings of i and j have changed significantly in the old design. An important consideration for selecting the new clock time corresponding to i=0 is that changing i should cause minimum disruption to safety. According to http://www.forbes.com/2009/01/21/car-accident-times-forbeslife-cx_he_0121driving.html, the fewest deaths by crash happened between 4 and 5 am on Tuesday. With the highest population density on the East Coast, 4:00 am Eastern Standard Time makes most sense as during Daylight Saving Time, it will move to 5:00 am, which is still consistent with the above article. Considering all these, i=0 corresponds to: 4:00 am Eastern Standard Time on Tuesday, January 6, 2015 (i.e., in TAI 4023 days, 9 hours plus 3 leap seconds or 347,619,603 TAI seconds since 1609.2 epoch).
Encryption of Pre-linkage Values by LA for PCA
In the old design, when LA sends pre-linkage values to RA for pseudonym certificate provisioning, it encrypts them for PCA using symmetric encryption. The secret key used for encryption is shared between LA and PCA through an out-of-band means. This has an impact on privacy (though only minor) from a malicious PCA, if RA uses more than one pair of LAs for a given PCA, as PCA can easily tell which pair of LAs were used in any given request sent by RA to PCA. This privacy impact can easily be mitigated if LA were to use public-key encryption for encrypting pre-linkage values for PCA, as a ciphertext generated using public-key encryption, does not need to contain any sender-related (in this case, LA) information. However, the team realized that using public-key encryption will add a significant amount of computational overhead on both LA and PCA, and decided to stick with symmetric encryption, with a recommendation for RA to keep the number of pairs of LAs per PCA as low as possible, ideally one.
Misbehavior Investigation: PCA Returns Encrypted Pre-linkage Values to MA
In the old design, during misbehavior investigation, PCA returns pre-linkage values to MA, which MA would then forward to LA. However, there is no need for MA to learn the pre-linkage values; PCA only needs to be able to point to a pre-linkage value that LA can then find information about. The design change is as follows: PCA returns an encrypted pre-linkage value to MA. The encrypted pre-linkage value matches the encrypted pre-linkage value that LA originally provided to PCA as part of the pseudonym certificate provisioning process.
The new design is described in Step 8.2: Misbehavior Investigation.
Crypto Primitives Affecting End-Entity
All of the changes mentioned below affect end-entities, and therefore they need to be informed to the V2V-SE team.