Patent Application
20220294645
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The invention is related to security in communications, in particular for scenarios that use pseudonym certificates to enable secure and privacy-preserving communications between vehicles.
In recent times, there has been a surge in digital technologies embedded in physical objects, leading to what is today known as Internet of Things (IoT). This trend has also reached the automotive industry, which has shown a growing interest in exploring interaction models such as Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) and Vehicle-to-Pedestrian (V2P), collectively referred to as Vehicle-to-Everything (V2X) communications. V2X enables several applications aimed at improving transportation safety, efficiency, and human to machine interaction. For example, with V2X, vehicles can exchange or communicate information (e.g., for velocity, direction and brake status) that can help drivers keep a safe distance from other vehicles while maintaining a suitable speed.
Indeed, the U.S. Department of Transportation has initiated a “connected vehicles” program “to test and evaluate technology that will enable cars, buses, trucks, trains, roads and other infrastructure, and our smartphones and other devices to ‘talk’ to one another. Cars on the highway, for example, would use short-range radio signals to communicate with each other so every vehicle on the road would be aware of where other nearby vehicles are. Drivers would receive notifications and alerts of dangerous situations, such as someone about to run a red light as they [are] nearing an intersection or an oncoming car, out of sight beyond a curve, swerving into their lane to avoid an object on the road.” U.S. Department of Transportation at https://www.its.dot.gov/cv_basics/cv_basics_what.htm. “Connected vehicles could dramatically reduce the number of fatalities and serious injuries caused by accidents on our roads and highways. [They] also promise to increase transportation options and reduce travel times. Traffic managers will be able to control the flow of traffic more easily with the advanced communications data available and prevent or lessen developing congestion. This could have a significant impact on the environment by helping to cut fuel consumption and reduce emissions.”
With the burgeoning of connected vehicles and V2X communication, security and privacy concerns are paramount. Such concerns are usually mitigated by combining cryptographic mechanisms with a suitable key management architecture. However, cryptographic operations may be quite resource-intensive, placing a considerable burden on the vehicle's V2X computing unit. Furthermore, existing protocols are potentially susceptible to security attacks.
This description and the accompanying drawings that illustrate aspects, embodiments, implementations, or applications should not be taken as limiting—the claims define the protected invention. Various mechanical, compositional, structural, electrical, and operational changes may be made without departing from the spirit and scope of this description and the claims. In some instances, well-known circuits, structures, or techniques have not been shown or described in detail as these are known to one skilled in the art. Like numbers in two or more figures represent the same or similar elements.
In this description, specific details are set forth describing some embodiments consistent with the present disclosure. Numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent to one skilled in the art, however, that some embodiments may be practiced without some or all of these specific details. The specific embodiments disclosed herein are meant to be illustrative but not limiting. One skilled in the art may realize other elements that, although not specifically described here, are within the scope and the spirit of this disclosure. In addition, to avoid unnecessary repetition, one or more features shown and described in association with one embodiment may be incorporated into other embodiments unless specifically described otherwise or if the one or more features would make an embodiment non-functional.
The following notations are used throughout the description:
Specifically, the SCMS combines an efficient and privacy-preserving method for vehicles to obtain large batches of pseudonym certificates (also known as butterfly key expansion), and an ancillary process for revoking the user's privacy in case of misbehavior, so that multiple certificates belonging to the same user can be linked together. Devices 102a-c, which may be a vehicle, a mobile device, and/or the like, may communicate through the SCMS infrastructure 103.
In SCMS, each device 102a-c receives two types of certificates: an enrollment certificate, which have long expiration times and identify valid devices in the system, and multiple pseudonym certificates, each of which has a short valid period (e.g., a few days). A number C (e.g., 1) pseudonym certificates may be valid simultaneously. For protecting the privacy, a particular vehicle (e.g., 102a or 102b) may then frequently change the pseudonym certificate employed in their communications, thus avoiding tracking by nearby vehicles or by roadside units. In some implementations, the number of pseudonym certificates C is usually limited to a small number to avoid “sybil-like” attacks, in which one vehicle poses as a platoon aiming to get some advantage over the system. For example, such a fake platoon could end up receiving preferential treatment from traffic lights programmed to give higher priority to congested roads.
SCMS is configured to allow the distribution of multiple pseudonym certificates to vehicles 102a-c in an efficient manner, while providing mechanisms for easily revoking them in case of misbehavior by their owners. As shown in
In some embodiments, the PCA 105 may include one or more distributed PCA(s), which are connected to a root certificate authority 118 via one or more intermediate certificate authority 117. The root certificate authority 118 may interface with the SCMS manager cloud 120 to receive control commands, configuration data, etc. from the manager could 120.
The SCMS infrastructure 103 further includes Linkage Authority (LA) modules, e.g., 115a-b. The LA modules 115a-b generate random-like bit-strings that are added to certificates so the certificates can be efficiently revoked (namely, multiple certificates belonging to the same device can be linked together by adding a small amount of information to certificate revocation lists (CRLs)). Although two LAs 115a-b are shown in the SCMS infrastructure 103, additional LAs may be supported.
The SCMS infrastructure 103 also includes a Misbehavior Authority (MA) 116 that is configured to identify misbehavior by devices and, if necessary, take appropriate action, for example, by revoking certificates. In some embodiments, the MA 116 revokes the certificates issued to the misbehaved devices by placing their certificates into a CRL. For example, the MA 116 includes a CRL generator 116c that adds the certificates of misbehaved devices to a CRL store 122 and broadcasts the revoked certificate information through a CRL broadcast module 124. If a transgression is confirmed, the MA 116 can collaborate with other system entities to identify the culprit, besides revoking its pseudonym certificates. This prevents malicious users or vehicles equipped with faulty components from disrupting the system for too long. Similarly, an elector-based trust management approach allows system authorities themselves to be revoked in case of misconduct.
As shown in
Memory 150S may be used to store software executed by computing device 150 and/or one or more data structures used during operation of computing device 150. Memory 150S may include one or more types of machine-readable media. Some common forms of machine readable media may include floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, EEPROM, FLASH-EPROM, any other memory chip or cartridge, and/or any other medium from which a processor or computer is adapted to read.
Processor 150P and/or memory 150S may be arranged in any suitable physical arrangement. In some embodiments, processor 150P and/or memory 150S may be implemented on a same board, in a same package (e.g., system-in-package), on a same chip (e.g., system-on-chip), and/or the like. In some embodiments, processor 150P and/or memory 150S may include distributed, virtualized, and/or containerized computing resources. Consistent with such embodiments, processor 150P and/or memory 150S may be located in one or more data centers and/or cloud computing facilities. In some examples, memory 150S may include non-transitory, tangible, machine readable media that includes executable code that when run by one or more processors (e.g., processor 150P) may cause the computing device 150, alone or in conjunction with other computing devices in the environment, to perform any of the methods described further herein.
Computing device or equipment 150 may include user interface 150i, e.g., such as present in a smartphone, an automotive information device, or of some other type device, for use by pedestrians, vehicle drivers, passengers, traffic managers, and possibly other people.
When compared to other VPKIs, one of the advantages of SCMS is its highly efficient pseudonym certificate provisioning process, called “butterfly key expansion.” Two versions of this process exist: (1) an original version, which may be referred to as “regular butterfly key” (RBK), and (2) an optimized version, which may be referred to as “unified butterfly key” (UBK).
First, the device (e.g., vehicle 102a) generates two caterpillar private/public key pairs 201, (s,S=s·G) and (e,E=e·G). The public caterpillar keys 201 S and E are then sent to the Registration Authority (RA 108) together with two suitable pseudorandom functions ƒs and ƒe. The key S is employed by the RA 108 in the generation of β public cocoon signature keys Ŝi=ƒs(i)·G, where 0i<β for an arbitrary value of β; similarly, the RA 108 uses E for generating β public cocoon encryption keys Êi=E+ƒe(i)·G. Pairs of cocoon keys Ŝi, Êi 205a-n generated through the butterfly key expansion process 203, from different devices are then shuffled together by the RA 108 and sent in batch to the PCA (or ACA) 105 for the generation of the corresponding pseudonym certificates.
After receiving the cocoon keys, the PCA 105 computes the device's public signature key 206a-n as Ui=Ŝi+ri·G, for a random value ri, inserts Ui into a certificate certi containing any necessary metadata, and digitally signs this certificate. The signed certificate 207a-n, together with the value of ri is then encrypted using Êi, so only the original device can decrypt the result to learn UL and compute the corresponding private signature key ui=s+ri+ƒs(i).
The encrypted data is also signed by the PCA 105 using its own private signature key, aiming to prevent an “honest-but-curious” RA 108 from engaging in a Man-in-the-Middle (MitM) attack. Namely, without this signature, a MitM attack by the RA 108 could be performed as follows: (1) instead of Êi, the RA 108 sends to the PCA 105 a fake cocoon encryption key Êi*=z·G, for an arbitrary value of z; (2) the RA 108 decrypts the PCA's response using z, learning the value of Ui; and (3) the RA 108 re-encrypts the certificate with the correct Êi, sending the result to the device, which proceeds with the protocol as usual. As long as the device verifies the PCA's signature on the RA's response, however, the attack would fail because RA 108 would not be able to provide a valid signature for the re-encrypted certificate 208a-n using the private signature key by PCA 105.
The user's privacy is protected in this process as long as the RA 108 and PCA 105 do not collude. After all, the shuffling of public cocoon keys 205a-n performed by the RA 108 prevents the PCA 105 from learning whether or not a group of keys in the batch belong to a same device. Unlinkability of public keys towards the RA 108, in turn, is also obtained because the latter does not learn the value of Ui, randomized by the PCA 105 using ri.
In essence, RBK requires vehicles to compute two sets of “caterpillar keys,” both created using, in some embodiments, Elliptic Curve Cryptography (ECC): the signature key pair (s,S←s·G) and the encryption signature key pair (e,E←e≠G). The vehicle 102 then establishes a secure communication channel with a RA 108 and sends to it: (1) the public keys S and E; (2) two pseudorandom functions, ƒ1 and ƒ2; and (3) long-term credentials (proving that it is authorized to request pseudonym certificates). The butterfly key expansion is then executed twice by the RA 108 during the pseudonym certification provisioning process: once for the signature keys S, and once for the encryption keys E. That is, the RA 108 expands each caterpillar public key into several “cocoon public keys” by applying the vehicle-provided ƒ1 and ƒ2. This leads to as many public key (S{circumflex over ( )}i←S+ƒ1(i)·G, E{circumflex over ( )}i←E+ƒ2(i)·G) tuples as the number of pseudonym certificates the vehicle 102 should receive. Subsequently, the RA 108 sends the individual tuples to the PCA 105, which is responsible for issuing pseudonym certificates. To preserve the vehicles' privacy, the RA-to-PCA requests are such that tuples corresponding to different vehicles 102 are shuffled together, and no information about the vehicles' identities is provided to the PCA 105.
The PCA 105, in turn, randomizes the received signature cocoon keys S{circumflex over ( )}i, obtaining the butterfly keys Ui←S{circumflex over ( )}i+ri·G. Those keys are signed by the PCA 105 together with any relevant metadata (e.g., a validity period), thus producing the corresponding pseudonym certificates certi. Finally, to prevent the RA 108 from learning the certificates' contents (and, thus, from linking certi to the requesting vehicle), the PCA 105 uses E{circumflex over ( )}i to encrypt its response to the RA 108. As a result, only the vehicle 102 can decrypt the received package using its private key e{circumflex over ( )}←e+ƒ2(i), and verify that certi was correctly issued. In addition, in RBK this encrypted package is also signed by the PCA 105 to prevent a malicious RA 108 from acting as a Man-in-the-Middle (MitM). Otherwise, the RA 108 might provide the PCA 105 with a bogus encryption key Eei, for which the RA 108 knows the private key. Then, it could decrypt the PCA's response, map certi to the vehicle's identity, and then re-encrypt everything with the correct E{circumflex over ( )}i to avoid suspicion. This extra signature by the PCA 105 in RBK leads to additional overheads in multiple places: on the PCA 105, for the computation and transmission of the extra signature; on the RA 108, for its reception and re-transmission; and on the end device 102, for the signature reception and verification, besides the verification of the certificate's signature itself.
The security of the RBK and UBK approaches or protocols are typically analyzed individually. However, if both RBK and UBK approaches are used in the SCMS environment (e.g.,
To complete the MitM attack, the rogue RA 108 also re-encrypts the pair {certi,ri} with Xbi, and sends the result to the requesting vehicle 102 as if the encryption was performed by the PCA 105. Since the response received by the vehicle 102 is identical to a genuine UBK package, in principle at 505 that vehicle 102 might believe that the certificates were indeed generated by an UBK-enabled PCA. Meanwhile, the rogue RA 108 learns the contents of all pseudonym certificates issued through it and, thus, can link the real identity of the vehicle 102 to those certificates when they are used in the field. Hence, the described co-existence attack violates one fundamental property of RBK and UBK: the unlinkability of pseudonym certificates by any (non-colluding) system entity. The privacy-by-design of the UBK process is lost.
According to some embodiments, systems and methods of the present disclosure can prevent or provide a countermeasure to the co-existence attack, for example, by ensuring or providing that vehicles 102 can verify which protocol (RBK or UBK) has actually been used by the PCA 105.
One approach for the countermeasure to prevent a co-existence attack involves using or including a protocol identifier in the PCA's certificate. In some embodiments, for example, the protocol identifier can be “0” to indicate RBK and “1” to indicate UBK, thus adding little overhead to the system. As a result, the vehicle 102 can check whether the PCA 105 runs UBK or RBK, and then verify the received pseudonym certificates' authenticity using the correct procedure. As long as PCA certificates for RBK do not share the same public key with any PCA certificate for UBK, vehicles 102 cannot be tricked into accepting RBK pseudonym certificates as if they were generated using UBK, thus preventing the co-existence attack. The overhead of this approach is negligible, since it can be as small as adding a single bit to the PCAs' long term certificates.
In another approach for the countermeasure to prevent a co-existence attack, the PCA 105 could use the pseudonym certificate's metadata itself to inform the vehicle 102 about which protocol (UBK or RBK) was employed for its generation. The overhead in this case can once again be as small as a single bit to differentiate between UBK and RBK. Nevertheless, this approach may be less efficient because: (1) there are many more short-term, pseudonym certificates in the system than long-term, PCA certificates; and (2) even though this extra bit is only useful during the issuance process, it must be transmitted afterwards when vehicles sign their own messages.
At 702, vehicle 102 initializes or sets its operation for the UBK protocol. In some embodiment, this initialization is based on an announcement from an RA 108 that it supports or can issue UBK certificates. At this point, it is not clear whether the RA 108 may be acting as a rogue, possibly attempting to breach or compromise security through a MitM attack.
At 704, based on the initialization for UBK protocol, vehicle 102 generates a single caterpillar private/public key for certificate request, according to normal UBK operation. At 706, vehicle 102 transmits the certificate request with the single public key pair to the RA 108 that announced UBK support.
The RA 108 computes the correct cocoon keys. If the RA 108 is a legitimate actor, it then forwards to the PCA 105 to obtain the certificates under the normal UBK protocol. On the other hand, if the RA 108 is a rogue actor, it creates a fake encryption key and presents this to the PCA (or ACA) 105 as a request under the RBK protocol.
The PCA 105 processes the request from the RA 108 in accordance with the protocol as presented by the RA 108. That is, if the RA 108 is a legitimate actor and presented the request under RBK protocol, the PCA 105 runs the RBK protocol for generating pseudonym certificates, encrypts it together with the randomization factor, and then signs this encrypted package. Alternatively, if the RA 108 is a rogue actor and presented the request under UBK protocol, the PCA 105 runs the UBK protocol for generating pseudonym certificates, but not signing the encrypted package. In either case, in accordance with some embodiments, the PCA 105 includes an indicator of which protocol (RBK or UBK) it employed or utilized. In some embodiments, the indicator can be a protocol identifier—e.g., “0” to indicate RBK and “1” to indicate UBK. In some embodiments, the PCA 105 use the pseudonym certificate's metadata itself to indicate which protocol (UBK or RBK) was employed. The PCA 105 then transmits the encrypted package (with protocol indicator) to the RA 108.
If the RA 108 is a legitimate actor, it processes the encrypted package according to the UBK protocol, and then transmits to the device or vehicle 102 (without compromising security). On the other hand, if the RA 108 is a rogue actor, it discards the final signature from the PCA's RBK response and recovers the corresponding certification, thereby compromising security. The rogue RA 108 transmits the package to the requesting vehicle 102 as if it had been processed or generated under the UBK protocol, even though the PCA 105 had actually processed under the RBK protocol; in particular, the package transmitted to the vehicle 102 does not include a signature.
At 708, the vehicle 102 receives the encrypted response from the RA 108, under the assumption that it has been handled or processed according to the UBK protocol, and thus no signature is present or required. At 710, the vehicle 102 decrypts the package without using a signature, as none would be required under UBK.
At 712, however, the device or vehicle 102 checks for the indicator (e.g., protocol identifier or certificate metadata) as to whether the PCA 105 processed the certificate request under the RBK or UBK protocol. If the indicator indicates that UBK protocol was employed (which would be the case for a legitimate RA 108), then at 714 the vehicle 102 will use the certificates. Alternately, if the indicator indicates that RBK protocol was employed (which would be the case for a rogue RA 108), then at 716 the vehicle 102 will discard the certificates. In some embodiments, the vehicle 102 will record data to note that this particular RA 108 is rogue, and possibly report to authorities in the SCMS environment so that suitable action can be taken (e.g., revocation of authority for the RA 108).
The execution or implementation of the countermeasure approaches is further shown in
As described herein, the systems and methods of the present disclosure—including aspects and operations of, for example, the vehicles or device 102 of SCMS—can be implemented in some combination of hardware and software. For example, as V2X technologies become pervasive, there is a need for a V2X gateway in the vehicle 102. Furthermore, to support the gateway with key management and cryptographic operations, an embedded Hardware Security Module (HSM) may be used.
Among the many security requirements for the V2X HSM, cryptographic operations (e.g., digital signatures and encryption) and key management are prominent features. The current requirement for processing V2X certificates (e.g., verification of cryptographic signatures and messages) is under 10 milliseconds, thus demanding faster cryptographic operations. And one proposal calls for digital signatures using ECDSA (Elliptic Curve Digital Signature Algorithm), as well as ECIES (Elliptic Curve Integrated Encryption Scheme) for the encryption of one-time session keys. Both ECDSA and ECIES are built upon elliptic curve arithmetic and a hash function, and ECIES additionally makes use of a symmetric cipher and a MAC. Supporting elliptic curves requires finite field arithmetic for operands much larger than the typical processor word size. Implementing symmetric algorithms efficiently in embedded system software can be a challenge when side-channel protection is required. In short, cryptographic operations may be quite resource-intensive, placing a considerable burden on the vehicle's V2X computing unit
To address this, in some embodiments, systems and methods of the present disclosure provide, support, employ, or implement hardware acceleration for HSMs, for example, for their cryptographic operations (e.g., common cryptographic primitives, such as block ciphers, digital signature schemes, and key exchange protocols). Hardware acceleration can be achieved in various ways, including either by connecting independent memory-mapped co-processor modules to the main central process unit (CPU), or by extending the CPU with custom instructions. In some embodiments, throughput and latency requirements can be used to determine or select which option for hardware acceleration is more suitable. In some examples, custom extension instructions are developed and employed since they achieve fine-tuned hardware acceleration with a low to moderate logic overhead, while also reducing code size.
As an example, some implementations of SCMS use or employ the PRESENT cipher block (as described below in more detail). The PRESENT cipher's round substitution and permutation operations can be implemented with a combinatorial logic datapath. Connecting such a datapath via a memory-mapped bus interface introduces significant processing latency, which is inherent to the process of moving data through the bus infrastructure. In comparison, an extensible processor platform allows for the same datapath to become an extension of the base Arithmetic Logic Unit (ALU), which can be accessed in software just like any other instruction. Thus, in a bit-sliced implementation of PRESENT cipher's substitution and permutation operations, dozens of regular CPU instructions can be replaced with a single custom extension instruction.
Replacing software operations by specialized instructions reduces code size, memory accesses and register usage. In addition to the reduced processing latency, the energy consumption decreases. Therefore, an extensible processor platform can provide or support hardware acceleration where fine-tuned improvements can be achieved with low logic overhead and reduced energy consumption.
One example of an extensible processor platform is based on the ARC EM Processor Family. The DesignWare® ARC® Processor IP portfolio from Synopsys includes a wide range of processors for embedded applications. The ARC EM Processor Family, based on the 32-bit ARCv2 instruction set, features a Harvard memory-processor architecture for simultaneous instruction and memory access. A broad set of digital signal processing (DSP), security and interconnection processor components allows these processors to be configured for highly specialized embedded applications. The ARC Processor EXtension (APEX) technology enables the integration of user-defined custom instructions, while the ARC XY Memory DSP Option brings a DSP engine for IILP in ARC EM processors.
APEX Technology. APEX technology allows for customization of the ARC processor implementation through user-defined instructions and auxiliary (AUX) registers. The provided pipeline interfaces allow for the implementation of specialized and enlarged-width datapaths. This enables smooth software integration, reduced interfacing complexity, lower gate count and processing output latency when compared to a bus-based co-processor.
ARC XY Memory DSP Option. Alongside the extension instructions, IILP can be achieved through the ARC XY Memory DSP Option, an Instruction-Level Parallelism (IILP) engine for fast and closely coupled memory access.
Some extensible processor platforms support the inclusion of custom logic via extension instructions. In these platforms, closely-coupled hardware interfaces are exposed for the connection of specialized logic modules into the main processor's pipeline. Such connections, however, can impose more restrictive critical path constraints: complex custom instructions with longer datapaths can decrease the processor's maximum clock frequency. One solution is introducing pipeline registers to split the instruction datapath into multiple stages, increasing the maximum clock frequency. This approach, however, increases the number of required registers, meaning larger chip area, as well as additional latency. Optionally, an instruction datapath with several pipeline stages can be divided into multiple instructions with shorter datapaths. In some embodiments, the throughput of these smaller collective instructions can be improved using Implicit Instruction-Level Parallelism (IILP) techniques.
Various encryption and security schemes and models are employed in SCMS. The original RBK expansion process proposed in SCMS uses or assumes use of Elliptic Curve Cryptography (ECC), which in some embodiments is implemented with or employs the Elliptic Curve Digital Signature Algorithm (ECDSA), the asymmetric Elliptic Curve Integrated Encryption Scheme (ECIES), and Advanced Encryption Standard (AES) block cipher. A UBK implementation for SCMS, in some embodiments, focuses on curves defined over prime fields which can be represented in the Montgomery (or Twisted Edwards) model, allowing faster formulas. In one version, the twisted Edwards representation of Curve25519 is known as “edwards25519.”
The edwards25519 curve enables the use of Edwards-curve Digital Signature Algorithm (EdDSA), which is a signature scheme variant of Schnorr signatures based on elliptic curves represented in the Edwards model. Like other discrete-log based signature schemes, EdDSA requires a secret value, or nonce, unique to each signature. In order to reduce the risk of random number generator failures, EdDSA calculates this nonce deterministically, as the hash of the message and the private key. Thus, the nonce is very unlikely to be repeated for different signed messages. This reduces the attack surface in terms of random number generation and improves nonce misuse resistance during the signing process. However, high quality random numbers are still needed for key generation. Given the aforementioned advantages of EdDSA over ECDSA, in some embodiments, EdDSA may be selected or used as the underlying signature algorithm for the UBK provisioning process.
For the encryption algorithm, in some embodiments, the symmetric PRESENT block cipher may be used or employed. The PRESENT block cipher is a lightweight block cipher algorithm, which is notable for its compact size (about 2.5 times smaller than AES), and as such, can be a desirable hardware implementation in the SCMS environment. A block cipher may employ or be implemented with one or more substitution boxes (S-boxes) and one or more permutation layers or boxes (pLayers or P-boxes). An S-box is a basic component of symmetric key algorithms which performs substitution; in block ciphers, S-boxes are typically used to obscure the relationship between the key and the ciphertext. A P-box or pLayer is used to permute or transpose bits across S-boxes inputs, retaining diffusion while transposing. In block ciphers, the S-boxes and P-boxes are used to make the relationship between the plaintext and the ciphertext difficult to understand.
In some embodiments, PRESENT block cipher's 4-bit substitution box (S-box) can be implemented as a lookup table. However, this approach is vulnerable to cache memory timing attacks. A constant-time and bit-sliced software implementation targeting ARM processors has also been presented. In this example, the 64-bit S-box layer is implemented as 14 Boolean operations over the four 16-bit word inputs, and 15 boolean operations for the inverse S-box counterpart. The proposed methods of interchanging permutations and S-boxes, and the decomposition of permutations resulted in substantial performance improvements for software implementations.
In some embodiments, systems and methods of the present disclosure apply custom extension instructions along with dual-data memory banks for the hardware acceleration of the PRESENT block cipher, as well as for the F2
The PRESENT block cipher's design can be implemented in a combination of hardware and software. In some embodiments, the systems and methods of the present disclosure employ or implement single-cycle non-blocking extension instructions or custom logic for the computation of PRESENT cipher's encryption, decryption and key update round. Because the PRESENT block cipher's size is 64-bits, two AUX registers can be used to implement a 64-bit datapath for the encryption instruction (enc64), and another two AUX registers for the decryption instruction. Likewise, four AUX registers are used in the implementation of a 128-bit datapath for the key schedule instruction (keysch). The table 1000 in
enc64 instruction datapath: In some embodiments, the PRESENT S-box implementation 1300 uses the boolean equations for the S-box output bits that are obtained from the application of Karnaugh mapping, followed by the Quine-McCluskey logic minimization algorithm. A Verilog code snippet for an implementation of the Boolean S-box for enc64 and keysch instructions, according to some embodiments, is provided below:
//
is the most significant bit
//
is the most significant bit
= (~
& ~
& ~
) | (~
&
&
) |
& ~
&
) | (
& ~
&
) |
&
&
);
= (~
&
& ~
) | (
&
& ~
) |
& ~
&
) | (~
& ~
& ~
) |
&
&
&
);
= (
&
&
) | (
& ~
& ~
) |
&
& ~
) | (~
& ~
&
) |
& ~
& ~
);
= (~
&
&
) | (
&
& ~
) |
& ~
& ~
) | (~
& ~
&
) |
&
& ~
& ~
) | (
&
& ~
&
);
The permutation layer (pLayer or P-boxes), which is used to permute or transpose bits across S-boxes inputs, can be implemented in hardware through simple bit-wiring. A Verilog code snippet for an implementation of the pLayer module, according to some embodiments, is provided below:
i; generate for (i=0; i<64; i=
) begin
]; assign out[i/4 + 32] = in [
]; assign
];
In some embodiments, the S-box layer is a module composed by sixteen instances of sbox together within a single module. As seen in
keysch instruction datapath: The 61-bit left rotation step of the PRESENT key schedule can be achieved similarly to the bit-wiring method used for the pLayer implementation. A Verilog code snippet for an implementation of the leftRot_61 module, according to some embodiments, is provided below:
i; generate for (i=127; i>=0; i=i
];
In some embodiments, in custom logic or module 1330, the datapath for the proposed keysch instruction is obtained by connecting the leftRot_61 module 1332, sbox modules 1334 and XOR gates 1336, as shown in
dec64 Instruction datapath: For the PRESENT cipher's inverse S-box module (isbox), the procedure used for the S-box module is repeated.
//
is the most significant bit
//
is the most significant bit
= (~
& ~
&
) | (~
& ~
&
) |
&
&
) | (
&
&
) |
&
& ~
& ~
) | (
& ~
& ~
& ~
);
= (~
& ~
& ~
) | (~
& ~
& ~
) |
&
& ~
) | (
& ~
&
) |
&
&
&
);
= (~
&
& ~
) | (
& ~
& ~
) |
& ~
&
) | (
&
&
) |
& ~
& ~
&
);
= (~
& ~
& ~
) | (~
& ~
& ~
);
&
&
) | (
& ~
&
) |
& ~
&
&
) | (
&
&
& ~
);
The inverse permutation layer (ipLayer) 1404 can also be implemented in hardware through simple bit-wiring. A Verilog snippet for an implementation of the ipLayer module 1404, according to some embodiments, is shown below:
i; generate for (i=0;
) begin : g
In some embodiments, the inverse S-box layer 1402 is composed of sixteen isbox module instances (Listing 4). The datapath of the proposed dec64 instruction is obtained by connecting the outputs of the ipLayer module 1404 to the inputs of the inverse S-box layer 1402, whose output is then wired to the 128-input XOR gate 1406 (i.e. addRoundKey), as depicted in
APEX integration: In order to integrate the instructions proposed in the table 1000 of
Instruction Extensions for F2
Characterization of F2
In some embodiments, the DesignWare MetaWare Debugger execution profiling tool is run over a reimplementation in software adapted to the Synopsys ARC. It is expected that the finite field multiplicative functions are the performance bottleneck in Curve25519 implementations. In the optimized software implementation of Curve25519, in some embodiments, the multiplicative operations are listed in the table 1600 of
In some embodiments, the field multiplicative operations are profiled using X25519 and Ed25519. The results show that around 80% of the total cycle count is consumed by the functions listed in the table 1600 of
256×256-bit multiplication: An initial challenge in designing custom instructions to improve the performance of the functions listed in table 1600 of
Consider the multiplication of a field element by a word (mul_word operation) using 32×32 bit multiplication as shown by the schoolbook multiplication scheme depicted in
Extending the multiplication scheme above for the subsequent product rows, it is evident that fe×fe full multiplication would require a 512-bit accumulator. A 512-bit accumulator unit would require larger register and adder units that would not be used to their full extent during the intermediary multiplication rows computation.
Referring to
Instruction set extension (ISE): A consideration when organizing instruction set extension (ISE) for the multiplicative operations listed in the table 1600 of
mul_word module: An initial step towards the implementation of the mul_word operation is the design of the smallest arithmetic unit: the 32×32-bit (word-by-word) multiplication unit with carry-in and carry-out signals. As the target platform for this work is an FPGA device, we can make use of the DSP slices to implement the mul32 modules.
The mul32 module 2210 is used as the building block for the implementation of the mul_word module 2200 shown in
APEX integration: For the integration of the instructions' datapath modules into the APEX pipeline, the AUX registers 2030 (e.g., FE0_AR, FE1_AR, FE2_AR, FE3_AR, FE4_AR, FE5_AR, FE6_AR, FE7_AR) are directly connected to the mul_word operation module 2020's field element input ports, as shown in
According to some embodiments, the systems and methods for hardware acceleration, e.g., in V2X environments, can be implemented with dual-data memory banks in hardware. One purpose of dual-data memory banks is to provide greater bandwidth. For example, among digital signal processing (DSP) mechanisms, dual-data memory banks (often referred as X and Y memory banks) have been incorporated in order to enable the simultaneous fetching of instruction data plus two-operand data. This enables greater memory access bandwidth for algorithms where repeated operations on arrays is done.
But using dual-data memory banks requires proper assignment of data to each memory bank, which can be a challenging task for obtaining optimal performance. This problem is illustrated through the code snippet of Listing 7, an example implementation of a dot-product with dual-data memory banks. We start by introducing this example using the C snippet below:
The code snippet shown above can be directly translated into the Assembly language implementation of Listing 6.
The traditional mul instruction is used in this example. The .ab tag specifies the post-increment address write-back mode for the load (ld) and store (st) instructions.
For the equivalent implementation using dual-data memory banks (i.e., XY Memory), assume that the arrays a, b and out are already mapped to the XY memory address space through the AGU registers % agu_r0, % agu_r1 and % agu_r2, respectively. Also consider that the corresponding AGU pointers get incremented by 4 bytes whenever % agu_r0, % agu_r1 and % agu_r2 are accessed. In such configuration, the dot-product can be implemented using XY memory as shown in the code snippet of Listing 7.
Given the comparison above, it is noted that the ARC XY Memory DSP subsystem (as shown in
It is also noted that implementations using XY memory inherit a code overhead regarding the initialization of the AGU registers and indexing modes. However, this overhead becomes negligible whenever looping over arrays of eight elements or more, due to the additional instructions required on the traditional load/store approach.
Cryptographic functions often get implemented using DSP-analogous repetitive array-based techniques, e.g., the PRESENT cipher's encryption/decryption rounds and F2
It is demonstrated herein how systems and methods of the present disclosure, according to some embodiments, combine the instruction set extensions (ISE) for PRESENT and F2
This section outlines an approach, according to some embodiments, for leveraging the ARC XY Memory DSP Option (as shown and described with reference to
In some embodiments, initially, it is demonstrated how the key schedule (keysch) function implemented using traditional load/store flow can be converted into the equivalent XY memory programming scheme. For the code snippets of Listings 8 and 9, assume that the % KEY0_AR, % KEY1_AR, % KEY2_AR and % KEY3_AR AUX registers (e.g.,
For the code on Listing 9, also assume that the round_keys_1 and round_keys_h are assigned to the X and Y memory banks 1202, 1204 (
By using the keysch instruction alongside the XY memory, it is possible to implement the key schedule algorithm's inner-loop rounds using 50% fewer instructions. For this particular case, the XY memory allocation is not critical, as there is no instruction which fetches two operands at the same time.
At this point, assume that the round key values are already computed and stored in the round_keys_1 and round_key_h arrays in the X and Y memory banks 1202, 1204. The code snippets of Listings 10 and 11 show the implementation of the encryption function's main loop (i.e., encryption rounds) according to the load/store flow and the equivalent XY memory flow. When comparing both code snippets, it is demonstrated that the encryption function's inner loop can be executed in a single cycle, with the enc64 instruction (e.g., as implemented in extension module 1320 of
The decryption function using the dec64 instruction follows the same logic, as shown by the code snippets of Listings 12 and 13.
The only difference here is that the final 64-bit decrypted message is stored in AUX registers % IBLK0_AR and % IBLK1_AR (e.g., AUX registers 1522, 1524 of
Continuing with the ARC XY Memory DSP Option, this section outlines the techniques for obtaining Implicit Instruction-Level Parallelism (IILP) with the developed instruction set extension (ISE) for F2
In some embodiments, initially, it is shown how to translate the fe×fe full multiplication operation from the traditional load/store implementation to the XY memory approach. For the fe×fe operation in Listings 14 and 15, consider that the 256-bit operand a is already held by the eight % FEi_AR AUX registers (e.g., AUX registers 2030 of
Weak reduction and non-multiplicative operations: In order to allow intermediate results to fit within 256 bits (8 words), some embodiments perform a modular reduction to 2256−38, exactly double the true field modulus of 2255−19. This is done to improve efficiency: the reduction to 2256−38 can be done using only addition with carry. Full reduction is done only once at the very end and requires some bit level manipulations, which is more costly timewise.
In addition to the fe×fe and weak reduction operations, some embodiments require fe+fe, fe−fe, and full reduction. In some embodiments, these non-multiplicative F2
Further details on weak reduction: The weak reduction itself can be explained: assume we have a 288 bit result in an array of nine words P[8], . . . , P[0] where P[8] is the most significant. Multiply P[8] by 38 and add it to P[7, . . . , 0]. Since the field elements are 256-bits long, addition, subtraction and multiplication by two will only carry at most one bit to P[8]. Which means if P[8]==1, then add 38 to P[7, . . . , 0]. Although simple, there are two corner cases to consider when P[7 . . . 0]>=2256−38:
If P[8]==0, then we would not add 38 and simply take the result in P[7 . . . 0] which would not be fully reduced mod 2256−38. This can be safely ignored, as all of the field arithmetic operations are designed to work with 256-bit inputs.
If P[8]==1, then adding 38 to P[7 . . . 0] will result in P[7 . . . 1] being 0 and P[0] being a very small value. In this case, it is necessary to add an additional 38 in order to achieve the correct reduction. As the weak reduction is an integral part of the field operation, it makes more sense to discuss the details of its implementation in that context. This is done below for the fe_add operation.
fe_add: The fe_add operation takes two 256-bit inputs in XY memory and stores the resulting sum to XY memory reduced to 2256−38. For this, we make use of the ARC processor's add with carry instruction: adc a, b, c # (a=b+c+carry).
Listing 16 is an implementation for fe+fe operation with XY memory.
In Listing 16, P0-P8 are arbitrary processor registers that correspond with the intermediate 288-bit results that become the input to the weak reduction.
The addition of the first word uses add since there is no previous operation that needs to be carried. The “.f” indicates that the carry flag should be set if the results of the addition overflows the 32-bit destination. The subsequent additions use adc which will then add the value of the previous operation's carry flag to the result. Technically, the most significant word P[8] should be 1 in the case of the final adc producing a carry, or 0 otherwise. This could be done using adc P8,0,0. However, in preparation for the weak reduction, it may be desirable to have 38 in the case of a carry as this is the value that needs to be added. This is accomplished using a conditional move instruction (mov.c): In the case of a carry, P8 will be set to 38, otherwise it will contain the previously set value of 0.
Listing 17 is an implementation for weak reduction operation after addition.
The code in Listing 17 immediately follows the previous addition and is a straightforward implementation of the weak reduction already discussed: P8 will contain either 0 or 38 which is added to the least significant word of the intermediate sum in P0. The following add with carry operations will propagate any additional carry as well as write the result to the destination XY memory. The jcc instruction is a conditional jump instruction (in this case, jump if carry not set): If the final adc did not generate a carry, then we are done and will return to the caller. If carry was set, then an additional 38 is added to P[0] and written to the output.
fe_sub: The fe_sub operation takes two 256-bit inputs in XY memory and stores the resulting difference to XY memory reduced to 2256−38. For this, we make use of the ARC processor's subtract with carry instruction: sbc a, b, c # (a=b−c−carry)
The implementation follows the same pattern as fe_add, except that all of the add/adc become sub/sbc.
fe_mul2: Several times in the high level elliptic curve functions we need to do a field multiplication by two. Using the existing field multiplication by a digit function (fe_mul_word) for this can be inefficient. Using the fe_add function to add the field element to itself would accomplish the task. However, this presents a problem when using the AGU 1206 to read the same value twice from the same memory bank, since this introduces an extra cycle of latency for every read. Alternatively, the rotate left through carry instruction allows for an efficient implementation of multiplication by two using a single input operand: rlc b, c # (b=c<<1; b=b OR carry).
For the first word's left shift, the asl instruction is used since there is no initial carry. For subsequent shifts rlc is used. The weak reduction is identical to that in fe_add.
fe_rdc: As previously discussed, the weak reduction that is done at the end of each field operation reduces the result modulo 2256−38 in order to keep the intermediate results within 256 bits. As the final step in a series of calculations, a final modular reduction to 2255−19 needs to be done. For this, we look at bit 256 of the intermediate output: If the bit is set, clear it and add 19 to the result. This code snippet is shown in listing 18, corresponding to a full reduction operation.
As we are only looking at bit 256, there is the corner case where the input value before reduction is in the range of 2255−1 and 2255−19. This would correspond with an elliptic curve point of 0-18.
Test vectors from both ISO/IEC 29192-2 standard and lightweightcrypto.com were used for verifying the intermediate and final outputs of the implementations for PRESENT block cipher described herein. Meanwhile, test vectors from RFC7748 and RFC8032 were used for verifying the implementations for hardware acceleration of X25519 and EdDSA, respectively, described herein.
In some embodiments for the testbed, the following ARC EM9D processor specifications were chosen: (1) ARCv2EM core, (2) DCCM and ICCM banks of size 65K each, (3) X and Y Memory banks of size 8K each, and (4) medium-sized AGU controller. All time measurements and verification procedures are performed over the DesignWare ARC xCAM cycle-accurate processor model tool. For the estimation of FPGA logic overhead introduced by the developed instructions' datapaths, the ARC's RTL processor model (containing the developed Instruction Set Extensions (ISE)) is synthesized targeting a Xilinx UltraScale XCZU9EG FPGA device.
Embodiments of the present disclosure provide improvement over previously developed implementations, as demonstrated by the results shown in
Referring to
Referring to
The embodiments described above illustrate but do not limit the invention. For example, the techniques described for vehicles can be used by other mobile systems, e.g., pedestrians' smart phones or other mobile systems equipped with computer and communication systems 150. The term “vehicle” is not limited to terrestrial vehicles, but includes aircraft, boats, space ships, and maybe other types of mobile objects. The vehicle techniques can be also be used by non-mobile systems, e.g., they can be used on a computer system.
This description and the accompanying drawings that illustrate inventive aspects, embodiments, implementations, or applications should not be taken as limiting. Various mechanical, compositional, structural, electrical, and operational changes may be made without departing from the spirit and scope of this description and the claims. In some instances, well-known circuits, structures, or techniques have not been shown or described in detail in order not to obscure the embodiments of this disclosure. Like numbers in two or more figures typically represent the same or similar elements.
In this description, specific details are set forth describing some embodiments consistent with the present disclosure. Numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent, however, to one skilled in the art that some embodiments may be practiced without some or all of these specific details. The specific embodiments disclosed herein are meant to be illustrative but not limiting. One skilled in the art may realize other elements that, although not specifically described here, are within the scope and the spirit of this disclosure. In addition, to avoid unnecessary repetition, one or more features shown and described in association with one embodiment may be incorporated into other embodiments unless specifically described otherwise or if the one or more features would make an embodiment non-functional.
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Thus, the scope of the invention should be limited only by the following claims, and it is appropriate that the claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.
This patent application is a continuation application of and claims priority to U.S. patent application Ser. No. 15/931,306, filed May 13, 2020 and entitled “Systems and Methods for Countering Co-Existence Attack,” and further claims priority to U.S. Provisional Patent Application No. 62/832,319, “ACCELERATED V2X PROVISIONING WITH EXTENSIBLE PROCESSOR PLATFORM,” filed on 11 Apr. 2019, which is expressly incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62832319 | Apr 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15931306 | May 2020 | US |
| Child | 17831308 | US |
