A Security Credential Management System for V2X Communications 95 equal to or later than some time i, e.g., the current week. The PCA calculates these linkage values by XORing pre-linkage values generated by the Linkage Authorities LA1 and LA2. The LAs can generate the pre-linkage values in advance. Figure 3 provides an overview of the linkage value generation. Let laid1, laid2 be 32-bit identity strings associated with LA1, LA2, respectively. For a set of certificates, first, the LA1, (resp., the LA2) picks a random 128-bit string called the initial linkage seed ls1(0) (resp., ls2(0)), then for each time period (e.g., a week) i > 0 calculates the linkage seed ls1(i) ← Hu(la_id1 ls1(i − 1)) (resp., ls2(i) ← Hu(la_id2 ls2(i − 1))). In this coherence, Hu(m) denotes the u most significant bytes of the SHA-256 hash output on m, and a b denotes concatenation of bit-strings a and b. We suggest using u = 16. Note that the linkage seeds (i.e., hash chains) created by the LAs have the property that it is easy to calculate forward (i.e., ls(i) from ls(i − 1)) but it is computationally infeasible to calculate backward (i.e., ls(i − 1) from ls(i)). Now the LAs calculate pre-linkage values utilizing a pseudorandom function. We choose to implement this by an encryption function, such as AES, in the Davies-Meyer mode. Each LA encrypts the linkage seeds as plvx(i, j) ← [E(lsx(i), (laidx j)) ⊕ (laidx j)]v, x ∈ {1, 2}, where E(k, m) is the AES encryption of m with key k, a ⊕ b is the exclusive-OR of bit-strings a, b, and [a]v denotes the v significant bytes of bit-string a. We suggest a flexible use of v to account for the number of deployed devices and potential weaknesses of the underlying cryptographic primitives concerning collision resistance. Currently, v = 9 appears to suffice. The value i denotes a time period (e.g., a week) and j denotes certificates within a time period (e.g., 20 certificates per week). Each LA calculates pre-linkage values in the same manner, but each with randomly selected initial seed. We denote the resulting values as plv1 and plv2. To select a specific linkage chain from an LA, we use Linkage Chain Identifiers (LCI)s. An LCI is the initial linkage seed ls1(0) or ls2(0) that LA1 or LA2, respectively, encrypts to itself, e.g., E(pk1, ls1(0)), where pk1 is the public key of LA1. The LAs encrypt pre-linkage values individually for the PCA but send them to the RA for association with a certificate request. The PCA XORs the pre-linkage values to obtain the linkage value lv = plv1 ⊕ plv2. Similar processing is required when a device processes the CRL. We present the details of this process and the information that the CRLG needs to publish in the section titled “Revocation and Blacklisting”. The PCA computes the linkage value to be included in a certificate by XORing together the two pre-linkage values from the LAs, which the two LAs generate independently and encrypt for the PCA to prevent the RA from colluding with one of the LAs and mapping pre-linkage values to linkage values. Therefore, no single component is able to link pseudonym certificates of a single device. The PCA creates individual certificates, which the RA collects and provides for download to the device. To prevent the RA from knowing which certificates belong to the same device, the PCA encrypts every individual certificate to the device. The PCA and the device use the butterfly key expansion process to encrypt each certificate with a different key.
96 B. Brecht and T. Hehn We refer the reader to [8] for more detailed information on linkage values, including a discussion of a reasonable length. This reference also includes a discussion of the misbinding attack concerning certificates retrieved from the SCMS. Detailed Description of Pseudonym Certificate Provisioning Process In the following, we present a detailed step-by-step description of the pseudonym certificate provisioning process illustrated in Fig. 4. • Step 1: The device creates a pseudonym certificate provisioning request by generating butterfly key seeds, signing the request with its enrollment certificate, attaching its enrollment certificate, and encrypting the request to the RA. The device then sends the request to the RA via LOP. The LOP functions as a pass- through device for requests. It obscures the device’s identifiers (e.g., IP address) by replacing these identifiers with its own, such that the request appears to the RA as originating from the LOP. The functionality of the LOP is very similar to the masquerading feature implemented in many Internet routers. • Step 2: The RA decrypts the request and validates the device’s enrollment certificate to authenticate the device and verifies that the device is not revoked. Further, it checks if this is the only request by the device. If all checks succeed, the RA sends an acknowledgment to the device and performs the butterfly key Fig. 4 Pseudonym certificate provisioning process
A Security Credential Management System for V2X Communications 97 expansion as explained in [8]. Otherwise, the RA rejects the request. The RA collects several such requests from different devices along with the sets of pre- linkage values received from the LAs. Once enough such requests are available, the RA shuffles the individual expanded requests to the PCA. Note that during pre-generation of additional pseudonym certificates, the RA requests pre-linkage values from each of the LAs for a particular initial linkage seed that is associated with that device using the LCI to identify the corresponding linkage chain. • Step 3: The RA sends requests for individual pseudonym certificates to the PCA, where each request consists of a to-be-signed certificate, a response encryption public key, one encrypted pre-linkage value from each of the LAs (plv1(i, j), plv2(i, j)), and the hash of the RA-to-PCA pseudonym certificate request. • Step 4: The PCA decrypts the pre-linkage values and computes the linkage value lv(i, j) = plv1(i, j) ⊕ plv2(i, j). It then adds the linkage value to the to-be- signed certificate and signs it to create a pseudonym certificate. It then creates a private key reconstruction value. Subsequently, it encrypts both the pseudonym certificate and the private key reconstruction value, using the response encryption key, which is part of the butterfly key expansion process [8]. • Step 5: The PCA signs the encrypted packet generated in Step 4 above, and sends it to the RA. Signing the encrypted packet provides a guarantee to the device that the PCA encrypted the packet for the device. This prevents a man-in-the-middle attack where an insider at the RA substitutes the valid response encryption key with another key for which the RA knows the private key, and thus the RA may be able to see the contents of the pseudonym certificate including the linkage value. • Step 6: The RA collects encrypted packages containing pseudonym certificate and corresponding private key reconstruction value for 1 week and bundles them for a given device - a so-called batch. The RA then provides the batches to the device for download. Removing Misbehaving Devices The removal of misbehaving devices in an efficient manner is an essential design objective. We separate the removal of misbehaving devices into (1) reporting misbehavior, (2) globally detecting misbehavior, (3) investigate misbehavior, and (4) revoking a misbehaving device. Misbehavior Reporting V2V messages from misbehaving or defective devices can contain false or mislead- ing information. We distinguish between intentional and unintentional misbehavior, where the latter includes all faults and error cases of devices. In both cases, it is crucial that benign participants neglect messages from misbehaving devices. One approach to accomplish this is to run misbehavior detection algorithms on
98 B. Brecht and T. Hehn the device (local misbehavior detection) to identify misbehaving nodes. Another approach is to report potentially misbehaving devices to the SCMS. The SCMS will run misbehavior detection algorithms and then inform all participants about certificates, which are no longer trustworthy. In the misbehavior reporting process, devices will send misbehavior reports to the MA via the RA. The RA will combine and shuffle the reports from multiple reporters to prevent the MA from tracking the reporter’s path based on the reports. A CAMP project currently defines the format of a misbehavior report. A report will include suspicious and alert-related BSMs, associated pseudonym certificates, a misbehavior type, as well as the reporter’s pseudonym certificate and corresponding signature from the time the report was created. The reporter will encrypt the report to the MA. In the following, we will focus on the process of Global Misbehavior Detection and Revocation for the case of OBE pseudonym certificates. Global Misbehavior Detection The global misbehavior detection (GMBD) is the overall process to identify poten- tial misbehavior in the system, investigate suspicious activity, and if confirmed, to revoke certificates of misbehaving devices. The MA owns and executes the misbe- havior detection process. A CAMP research project has developed some GMBD algorithms. CAMP will integrate those into the current SCMS implementation. However, as the V2X landscape continues to evolve and new threats and forms of misbehavior are discovered, it is expected that additional algorithms will continue to be developed and implemented over time. Misbehavior Detection methods and algorithm development are seen as iterative tasks that will continue throughout the lifetime of the SCMS. One example of misbehavior, however primitive, would be a malicious actor who intentionally projects the position of the sending vehicle 3 m to the left (or right for right-hand drive countries). These messages would cause alerts to the oncoming traffic, which oncoming vehicles would detect as possible misbehavior. A receiving vehicle would store these messages (assuming multiple) and put them into a misbehavior report, along with all defined data and details. It would encrypt the report to the MA and send it to the RA for submission to the MA. As other vehicles also detect this misbehaving vehicle, they would also send misbehavior reports to the MA. As the number of reports grows, it would trigger the misbehavior detection algorithms and initiate the misbehavior investigation process possibly leading to the revocation of the malicious device’s certificates. It is worth noting that the sending vehicle could handle this type of misbehavior locally. We expect OEMs and device developers to tackle misbehavior at the device level from many angles to detect and prevent malicious messages from being sent or used within safety applications. Misbehavior Detection requires that the MA can learn whether multiple mis- behavior reports point to the same device. It also requires the MA to collect information that it publishes in a CRL to revoke a device’s certificates. Additionally, the MA needs to provide the RA with the information required to perform black-
A Security Credential Management System for V2X Communications 99 listing which blocks the revoked device from getting new certificates. The SCMS design requires the following components to collaborate to support misbehavior detection which introduces a form of checks and balances: 1. The MA, PCA and one of the LAs have to collaborate to reconstruct linkage information. 2. The MA, PCA, RA, and both the LAs have to collaborate to produce revocation information for the CRL. 3. The MA, PCA, and the RA have to collaborate to determine the enrollment certificate of the misbehaving device, which the RA will add to its blacklist. The MA executes step 1 as part of the Misbehavior Investigation to determine whether a device or a set of devices did indeed misbehave. After MA marked a device as misbehaving, MA executes steps 2 and 3 as part of Revocation to determine revocation information for the CRL and the enrollment certificate that RA adds to its blacklist. Misbehavior Investigation Misbehavior Investigation is the process to determine whether suspicious activities are indeed due to misbehavior, and to identify misbehaving devices. The Misbe- havior Detection algorithm running in the MA initiates a process that depends on inputs from PCA and one LA. This separation introduces checks and balances into the system. We recommend a mechanism that limits the number of requests PCA and LA accept as well as the amount of information returned to MA to protect privacy to the highest level possible. Finally, we recommend that PCA and LA keep records of every request and that the SCMS Manager audits these log files regularly. In the following, we present a detailed description of this process. Note that the first two steps are included for completeness and cover Misbehavior Reporting and Global Misbehavior Detection. • Step 1: The MA receives misbehavior reports, including a reported pseudonym certificate with linkage value lv = plv1 ⊕ plv2. • Step 2: The MA runs global misbehavior detection algorithms to determine which reported pseudonym certificates might be of interest, i.e., for which pseudonym certificates it needs to retrieve linkage information. • Step 3: The MA requests the PCA to map the linkage values lv of the identified pseudonym certificates to the corresponding encrypted pre-linkage values (plv1, plv2) from the PCA’s database. The PCA returns the encrypted pre-linkage values to MA. • Step 4: The MA requests either LA1 or LA2 to find out whether a set of encrypted plv1 (or, resp., plv2) point to the same device. The LA will only respond if the number of encrypted plv pointing to the same device is above a defined threshold (e.g., five). There may be additional protective measures to reduce the amount of information returned to the MA.
100 B. Brecht and T. Hehn Note: While the steps above illustrate the basic misbehavior investigation process, at the time of writing the process of misbehavior detection and investigation is still being researched with focus on optimization of processes, improving privacy protections, identifying malicious or colluding reporters, etc. Revocation and Blacklisting The MA revokes and blacklists a device if MA determines during Misbehavior Investigation that the device was indeed misbehaving. In the following, we present a detailed description of the process to identify the linkage seeds and the enrollment certificate corresponding to a pseudonym certificate. Figure 5 illustrates this process, with the first two steps summarizing the Misbehavior Investigation. • Step 3: The MA requests the PCA to map the linkage value lv of the identified pseudonym certificate to the corresponding hash value of the RA-to-PCA pseudonym certificate request. The PCA returns this value and the hostname of the corresponding RA to the MA. • Step 4: The MA sends the hash value of the RA-to-PCA pseudonym certificate request to the RA. The RA can map the hash value to the corresponding enrollment certificate and add it to its blacklist. The RA does not reveal the enrollment certificate to the MA. The MA receives the following information h DB Step 3, MA → PCA PCA Linkage value lv (i, j) Step 3, PCA → MA Hash of RA-to-PCA request h RA hostname Step 4, MA → RA: Hash h Step 4, Action: lci1, lci2 DB Add enrollment Step 4, RA → MA: certificate to blacklist MA Identifiers lci1, lci2 RA LA1, LA2 hostname Step 5, MA → LAx: Linkage Chain Identifiers lci1, lci2 Step 5, LAx → MA : LA1 ls1(i) DB Revocation Information ls1(i), la_id1, ls2(i), la_id2 LA2 ls2(i) DB Fig. 5 Revocation and blacklisting
A Security Credential Management System for V2X Communications 101 from RA, which is then used by MA to gather information necessary for active revocation: – The hostnames of the LAs involved in creating the pseudonym certificate’s linkage value. – An array of LCIs for each LA. The LA can use an LCI to look up the linkage chain and the underlying linkage seed. The RA returns multiple linkage chain identifiers only if a device owns certificates from multiple independent linkage chains, which we consider an exception. • Step 5: The MA requests the LA1 (resp., the LA2) to map LCI lci1 (resp., lci2) to the linkage seed ls1(i) (resp., ls2(i)), where i is the currently valid time period. Both the LAs return their linkage seed to the MA. Further, each LA provides to MA its linkage authority ID (laidi). Note that given a linkage seed ls1(i) and the corresponding laidi, only the forward linkage seeds (i.e., ls1(j) for j ≥ i) can be calculated, and thus backward privacy of the revoked device is maintained. • Step 6: MA adds the linkage seeds ls1(i) and ls2(i), and the corresponding pair of LA IDs laid1, laid2 to the CRL. The CRL globally states the current time period i. For efficiency reasons, the CRL may group entries with the same LA ID pair together to save over-the-air bytes. Then the MA instructs the CRLG to sign the updated CRL and publish it. The size of the CRL grows linearly with the number of revoked entities. The assumption is that all OEMs will provide at least enough storage for 10,000 entries, which translates to a file size of approximately 400 KB. Therefore, a good CRL design will tag entries with information that allows devices to identify the 10,000 entries that are of highest priority to them: for example, entries could be tagged with a location, or with the severity of misbehavior associated with that device, or with an indicator that the private keys have been made public. At the time of writing, the final CRL design is still under development. IEEE [14] provides a preliminary design. Note that currently there is no way to undo a revocation, and a revoked device can be reinstated only by repeating the process of bootstrapping, compare sections “Re-enrollment” and “Bootstrapping”. Revocation and Tracking The value of having multiple linkage authorities is that it prevents an insider from gaining information that would enable him to track a vehicle, while at the same time allowing identification of a specific device under controlled circumstances. There are two circumstances where this is useful: • Revocation: as described above, the LAs enable efficient revocation via CRLs. • Misbehavior detection: If part of the misbehavior detection process is to check whether two messages, signed with different certificates, origin from the same device, then the LAs can be used to support this internal investigation in
102 B. Brecht and T. Hehn a privacy-preserving manner. It is still a subject of research to determine what information LAs should be allowed to provide to MA, and under which circumstances. Elector-Based Root Management Given that devices can re-enroll as described in section “Re-Enrollment,” how can a device start trusting a new root CA certificate after the previous certificate’s validity period has ended or a revocation of the certificate was necessary? The trust in an initial root CA certificate is implicit, as it is installed in a secure environment with out-of-band communication during bootstrapping of the device. One option would be to get the device back to that secure environment and use out-of-band communication to install the new root CA certificate. However, this is suboptimal due to the required effort and will render the overall V2X system partly out-of-order until all devices have installed the new certificate. To manage the root CA certificate over time and gain resilience against com- promises on any level, the SCMS needs the ability to heal itself, which means to bring itself into a state where it can endure another singleton compromise or end of the validity period of a Root CA. This recovery should occur while keeping the devices operational whenever possible, that is, capable of sending, receiving and validating V2X messages, and be able to restore the system hierarchy without requiring physical access to devices. Elector-based Root Management is the solution that provides those means by installing a distributed management schema on top of the SCMS Root CAs. Distributed Management and Electors A distributed management scheme, like a democracy, contains within itself the power to replace an established hierarchy and does not succumb to a single failure. The concept of Electors, which together have the power to change and manage the trust relationships of the system, adds such a scheme to the SCMS design. Within a system like the SCMS, the number of electors should be 2n + 1, where n is the number of simultaneous elector expiration/compromises that the SCMS can tolerate. Like in a democracy, the Elector-based Root Management introduces a Ballot with Endorsements. The electors cast votes by signing an endorsement of a given root CA or elector certificate. A ballot aggregates all these endorsements. When a quorum of valid elector endorsements is on the ballot, any component in the system can trust the ballot. The electors are not part of the PKI hierarchy, and therefore they can use a different crypto-system than the SCMS PKI. In fact, each of them can use a different one. This raises the probability that in case of a root CA or elector certificate compromise due to a broken cryptography, the system is still able to heal itself.
A Security Credential Management System for V2X Communications 103 The resulting system may have multiple, self-signed root CA certificates, each of which operates at the top of their trust chain. Each root CA’s certificate is endorsed by a ballot with at least a quorum of votes from non-revoked electors. Devices need to verify the trust chain up to a root CA certificate, at which point they must verify that a quorum of non-revoked electors has endorsed that root CA certificate. Ballots and Endorsements Electors operate by signing endorsements. A ballot can include the following types of endorsements: • Add root CA certificate • Add elector certificate • Revoke root CA certificate • Revoke elector certificate Each ballot contains only one type of endorsement. SCMS components, includ- ing devices, receive ballots adding a certificate via a certificate chain file distributed by the PG. They receive ballots revoking a certificate via the CRL distributed by the CRL store. All components know the quorum and the certificates of the initial set of electors and therefore can validate the endorsements contained in the ballot. Once the ballot is validated, the component can follow the endorsed action to add or remove the ballot’s certificate from its trust store. The SCMS Manager will coordinate the production of the ballot messages. Structure of Ballots The ballot which aggregates all independent elector endorsements is an ASN.1 structure. This structure contains the following elements: • The certificate of the root CA or elector to be endorsed • A sequence of endorsements, each containing: – The type of endorsement – The hash id of the certificate to be endorsed – The generation time of the endorsement – A signature of the elector Note that the validity period of a ballot is implicitly given by the validity period of the endorsed certificate.
104 B. Brecht and T. Hehn Discussion of Alternatives to the SCMS Concept Several alternative approaches for a V2X security system have been discussed in literature with their own advantages and disadvantages. We will give an overview starting from the most basic to more elaborated systems and highlight why the SCMS seems to be the only viable alternative so far. Some of those approaches are basic building blocks of the SCMS, partly changed and enriched to gain the necessary characteristics as outlined in section “Requirements for a V2X Communications Security System”. Symmetric Key Management Symmetric key cryptography uses the same key for encryption and decryption. Therefore, the key needs to be kept private between participants and need to be pre-shared. Although symmetric key cryptography algorithms are significantly faster than, e.g., asymmetric key algorithms, they are not suited for use in a V2X environment: • In a system with symmetric key management, at least two participants (sender and receiver) use the same key. In such a system, authenticity and non- repudiation are impossible to achieve, as the message cannot be unambiguously traced back to exactly one device. This also makes misbehavior detection and revocation impossible. • Symmetric keys can either be pre-shared or loaded from the network when needed. Pre-sharing of unique keys for each pair of devices is not practical due to storage limitations; loading them on-demand requires ubiquitous connectivity. • In case symmetric keys are pre-shared, they become the single most valuable target for attackers, as once they gained access, they could participate in the system. Once that happens, all legitimate devices using this key would need to change the pre-shared key. Meanwhile, the overall V2X system is rendered insecure. PKI Solutions Public Key Infrastructure (PKI) solutions use asymmetric key cryptography and add the necessary infrastructure to enable an ad-hoc secure exchange of public keys: It establishes one or multiple authorities that both sender and receiver trust. The authority verifies the sender to be a valid participant and that he indeed is in sole possession of the private key. It legitimates the sender by signing his associated public key, using a digital certificate containing the public key, optionally additional information, e.g., a name and a validity period, and the signature of the authority.
A Security Credential Management System for V2X Communications 105 This certificate reflects the existing trust relationship between the issuer of the digital certificate, which is therefore called certificate authority (CA), and the certified entity, in this case, the sender. The sender attaches this certificate to his digitally signed message. The receiver verifies the CA’s digital signature on the certificate, and as long as the receiver trusts the CA, it can trust the sender to be a valid participant. The receiver uses the certificate’s public key to verify the sender’s signature attached to the message and with that the authenticity and integrity of the message itself. A PKI often adds additional infrastructure, e.g., to split responsibilities of ensuring that only legitimate senders get a certificate and revoking them through the publication of a certificate revocation list (CRL). It organizes them in a certification hierarchy with a root authority at its highest level. That way every CA, located at a lower level, has a certificate, including a public key, signed by a CA from a higher level. The root CA holds a self-signed certificate, i.e., it uses its private key to sign its certificate. All participants in the PKI trust the root CA and trust flows down to all subordinate CAs. From a pure security perspective, a PKI would be a candidate technology for a V2X security system, as it fulfills these requirements: • Trust is maintained as long as the sender keeps his signing key secret • Authenticity is given if only valid V2X participants get a certificate that is signed by a trusted PKI authority • A receiver can quickly verify an incoming message • The PKI revokes compromised senders promptly • The PKI notifies message receivers of revocations promptly Although all identifying characteristics might be removed from a certificate, and some call this an anonymous certificate, the public key is still an identifying characteristic that in a V2X system can be used to correlate locations of a specific sender, as it does not change. Therefore, PKIs do not meet the additional privacy requirements. Group Signatures Group signatures, as introduced by Chaum and van Heyst [15], are digital signatures with one distinctive feature: multiple potential signers are considered to form a group, for which each signer can create a signature on behalf of the whole group. Such a signature is verifiable using the public key of the entire group. Only one dedicated party, the so-called group manager (GM), can link the signature to the identity of the signer, creating some anonymity for the actual signer within the group and towards external verifiers. In the most basic setting, the architecture of a group signature system consists of the GM and multiple group members. The GM is responsible for the initialization of the group, the admission, and revocation of group members.
106 B. Brecht and T. Hehn As [16] present in more detail, during initialization, the GM creates his secret key, the group public key, and defines group parameters. The GM issues dedicated membership certificates to group members using his secret key. The membership certificate represents the secret signing key of the respective group member that it can use to produce group signatures on arbitrary messages. Given the signature, every verifier can validate the message using the group public key and therefore verify that the signer belongs to the group. In case of a dispute, the group manager can open a group signature and identify the signer, using information collected during the provisioning process of the membership certificate. If necessary, the group manager can then revoke the membership certificate of that group member. Group signatures have extended security requirements (as compared to con- ventional digital signatures, additional requirements are highlighted in italic-face typesetting): • Unforgeability: only group members can create valid group signatures • Privacy: given a message and its signature, the identity of the individual signer cannot be determined without the group manager’s secret key. • Unlinkability: no other party, except for the group manager, can link two or more signatures created by the same signer • Traceability: given any valid signature, the group manager should be able to trace which user created the signature • No framing: Even if all other group members (and the group manager) collude, they cannot forge a signature for a non-colluding group member. • Unforgeable tracing verification: The group manager cannot falsely accuse a signer of creating a signature he did not create • Coalition resistance: A colluding subset of group members cannot generate a valid signature that the group manager cannot link to one of the colluding group members Unforgeability and traceability imply that only the group manager can break users’ group anonymity. This basic concept allows for different flavors of group signature schemes, which can be classified based on their functionality following [16]: • Static group signatures • Dynamic group signatures • Group signatures with verifiable opening • Group signatures with distributed authorities • Group signatures with special properties Static Group Signature Schemes Static group signature schemes have all the characteristics as laid out before, but the number of group members is set during initialization and cannot be changed subsequently. Schemes of this type consist of four main algorithms:
A Security Credential Management System for V2X Communications 107 1. Key generation (executed by the group manager): This algorithm creates the public key of the group, the secret key of the group manager and a secret signing key for each group member 2. Signature generation (executed by each group member): This algorithm creates a group signature by using the member’s secret signing key 3. Signature verification (executed by any verifier): This algorithm proves that the signature was created by a group member using the public group key 4. Opening (executed by the group manager): This algorithm identifies the creator of a (valid) group signature using the group manager’s secret key Dynamic Group Signature Schemes Dynamic group signature schemes allow on-demand admission of new members and do not require prior knowledge of the number of members. The key generation algorithm differs from the one in the static scheme. It only creates the group manager’s secret key and the public key of the group, but not secret signing keys for members. One additional algorithm adds this functionality: 5. Join (executed between the group manager and a prospective group member): In this algorithm, the secret signing key is created and transferred securely to the group member. This modified join algorithm also creates some information that the group manager can later use in the opening algorithm to identify a group signature created by that member. All other algorithms are performed in the same way as in static schemes. Dynamic group signature schemes have an additional characteristic: besides adding members, they may provide algorithms to remove a member from the group through membership revocation. Two additional algorithms enable this: 6. Revocation (executed by the group manager, e.g., after executing the opening algorithm to identify a misbehaving group member): This algorithm updates some public group information to indicate the revocation of a specific member. 7. Update (executed by each remaining group member): In this algorithm, a remaining group member updates his secret signing key. Group signature schemes with the property of verifier-local revocation handle this differently: the GM publishes a revocation list that is used by verifiers to check locally whether a revoked signer created a given signature. The remaining members do not need to update their secret key in those schemes. Group Signature Schemes with Verifiable Opening Group signature schemes with verifiable opening add yet another characteristic: neither static nor dynamic group signature schemes prevent the group manager during the opening algorithm to accuse falsely a particular signer of having created
108 B. Brecht and T. Hehn the signature. Therefore, this requires full trust in one intrinsically central authority, the group manager. As a countermeasure, group signatures with verifiable opening modify the opening algorithm and require the group manager to provide some publicly verifiable proof that the identified (and potentially subsequently revoked) group member is indeed the member that created the disputed signature. This extension requires one additional algorithm: 8. Judgement (executed by verifiers using the proof that the group manager produced during the opening algorithm): This algorithm verifies that the disputed signer did create the disputed signature. Many schemes with verifiable opening utilize a public key infrastructure and the signer’s certified public key to identify him in a publicly provable way. This public key is linked to his group membership credentials and used during the executing of the join algorithm with the GM. Therefore, at least one additional algorithm is required: 9. User key pair generation (executed by each user): In this algorithm, each user generates their own private/public key pair using an appropriate key generation algorithm. Group Signatures with Distributed Authorities Group signature schemes with distributed authorities enable a separation of duties of the group manager, e.g., to reduce the amount of trust placed into it. These schemes allow for splitting the two primary tasks of the group manager (management of group membership and the opening of signatures to identify a signer), so two separate authorities can implement them. An issuer is an authority responsible for group membership management (join and revocation algorithms), whereas an opener is an authority responsible for identifying a signer. The security properties of such a scheme reflect this separation of duties, and therefore the issuer would not be able to identify a signer, whereas the opener would not be able to grant or revoke membership credentials. These schemes require a distributed key generation algorithm which generates the public key of the group, a private key for the issuer and a private key for the opener, and in static schemes secret signing keys for all members of the group. Group Signatures with Special Properties There are other group signature schemes, like group blind signatures, democratic group signatures, or mediated group signatures, but they do not add any characteris- tic useful to a potential V2X security system, which is why we do not elaborate on them further. For further details see [16].
A Security Credential Management System for V2X Communications 109 Disadvantages of Group Signatures There are significant disadvantages to group signature schemes from the perspective of a V2X system: • The size of signatures, keys and the group certificate are significantly larger than in conventional asymmetric key cryptography schemes using elliptic curve cryptography (ECC). That results in less communication capacity over the air for devices exchanging messages. • Computational requirements are higher compared to ECC. • The group manager has insider knowledge to identify individual devices by their signature and therefore does not meet privacy requirements for protection against insider attacks Vehicle-Based Security System Carter and Zhang propose in [17] a V2X security system, based on previous work by [18–20] who suggest to use group signatures for V2X communication, where each OBE has its own certificate authority (CA). Following the work of [19] they propose that an OBE generates short-term certificates to sign V2X messages using the elliptical curve digital signature algorithm (ECDSA). However, to legitimate the OBE’s certificate authority, they utilize a dynamic group signature scheme. They call this a vehicle-based security system (VBSS) as devices themselves generate the certificates required for V2X communication. That way they gain anonymity within the group of devices and at the same time the efficiency of elliptic curve cryptography. Their goals with the proposed system are: • To minimize the size and complexity of the supporting infrastructure • To minimize the infrastructure dependencies necessary for certificate provision- ing • To improve message anonymity and unlinkability through cryptography • To retain the performance of ECDSA • To facilitate a scalable revocation system without the use of a CRL • The Group Signature Scheme chosen must meet the same cryptographic strength as the cryptographic scheme of the SCMS The fundamental idea is that a vehicle becomes a member of a vehicle group by executing the join algorithm with an eligible group manager and gets a secret group signing key during the procedure. Message Authentication Message creation and authentication in a VBSS follow these steps:
110 B. Brecht and T. Hehn • A sender creates an ECDSA public/private key pair with similar characteristics as the public/private key pair used in the SCMS for pseudonym certificates. • The sender signs the public key with its secret group signing key to create the pseudonym certificate. • The sender uses the private key corresponding to the pseudonym certificate to sign a message and attaches the pseudonym certificate. • The receiver will verify the message’s signature with the attached pseudonym certificate and the group signature in the pseudonym certificate using the group certificate of the group manager. • The receiver establishes trust in the message if both verification algorithms return valid results and the receiver trusts the group manager. A chain of trust from the group certificate up to a Root CA legitimates trust initially, similar to the SCMS chain of trust. The next subsection will give an overview of the VBSS architecture, the establishment of initial trust and the chain of trust. Similar to the SCMS approach of message verification, there are several opti- mization strategies: • The VBSS policy could establish a pseudonym change strategy, which allows the sender to use the same pseudonym certificate for a short period (e.g., 5 min), instead of using a new pseudonym certificate for each message. – This allows the receiver to verify the pseudonym certificate once, cache the result and whenever he receives another message with the same pseudonym certificate, he would not need to verify the group signature and the whole chain of trust – This, in turn, allows the sender not to attach the pseudonym certificate to every single message, but, e.g., with the same rate as in the SCMS system (e.g., two times a second) to save over-the-air bytes. • Once a receiver established trust in a particular group certificate, it can cache the result and does not need to verify the whole chain of trust until the group certificate changes. This approach achieves anonymity with the use of group-signed ECDSA pseudonym certificates and unlinkability through a regular change of that certificate. Architecture Figure 6 gives a conceptual overview of the VBSS architecture. We list the description of components from top to down in the following. • VPKI Manager (VPM): Equal to the SCMS Manager in the SCMS concept a governing body for the overall system.
A Security Credential Management System for V2X Communications 111 VPKI Manager Group Certification Root CA MA Broadcast Services Intermediate CA LOP DCM Group Manager RSE OBE RSE OBE Connections Legend: Components Legend: V2V + V2I information Credentials Intrinsically central Out-of-Band communications component LOP Communications through LOP Fig. 6 VBSS architecture • Root Certificate Authority (RCA), Intermediate Certificate Authority (ICA), Certification Services (CS), and Location Obscurer Proxy (LOP): Equal to the corresponding SCMS components. • Misbehavior Authority (MA) and Global Detection (GD): Similar to the SCMS MA with the difference that instead of check and balances between multiple components during misbehavior investigation the MA just reaches out to the Group Manager to ask for identification of a device. • Device Configuration Manager (DCM): Similar to the SCMS DCM it attests to the Group Manager that a device is eligible to receive a secret group signing key, and provides all relevant configuration settings and certificates during the join algorithm. • Group Manager (GM): A group manager as defined in group signature schemes that support algorithms for group management, as well as verifiable opening. More information is provided in section “Group Management” below. • Group Broadcast (GB): Distributes group credential updates, e.g., in case of a revocation
112 B. Brecht and T. Hehn The similarity to the SCMS architecture allows the VBSS to take over advance- ments of the SCMS whenever they fit into their architecture, e.g., elector-based root management. Group Management Within the VBSS, the GM initializes, assigns, and modifies the group credentials each vehicle uses to sign its self-produced pseudonym certificates. During the join algorithm, the GM assigns each vehicle to a single group following a group division scheme, provides a secret group signing key, and a set of group certificates from other Group Managers to allow for the vehicle to authenticate messages from devices of other groups. The GM distributes updates periodically via the GB to reflect changes in group composition. The group division scheme is defined by the VPM and divides the vehicle population into disjoint groups, e.g., by vehicle manufacturer or geographical region [17]. As the GM has knowledge about group membership, secret keys, and has the power to identify group members by their signature, [21] recommend to split responsibilities and critical data to protect against insider privacy attack. They recommend using “Group Signatures with Distributed Authorities” to split the GM’s responsibilities. Additionally, two independent authorities should manage the data used during the opening algorithm in a way that requires collusion during the opening algorithm. This approach is similar to the SCMS concept of organizational separation (compare section “Organizational Separation”). The VBSS uses the strategy of broadcasting group credentials and update information for revocation ([22–25]. Comparison VBSS and SCMS The Vehicle-Based Security System as presented fulfills all requirements necessary for a V2X communication system as defined before in section “Requirements for a V2X Communications Security System”. It achieves message integrity and authenticity similarly to the SCMS by using ECDSA signatures to ensure the integrity and a PKI chain of trust to verify authenticity. One advantage of the VBSS over the SCMS is its capacity to protect privacy better by generating pseudonyms “on demand” and mitigating pseudonym reuse entirely. Whereas the SCMS either needs to create many certificates that are potentially never used or agree to a certain degree of re-usage depending on the certificate change strategy and the number of issued certificates per week. The VBSS, therefore, fulfills requirement #4 in section “Requirements for a V2X Communications Security System” to a higher degree compared with the SCMS. With the split of the Group Manager as well as the split of data required for the opening algorithm to be managed by two different entities, it fulfills the last requirement as well.
A Security Credential Management System for V2X Communications 113 However, there are disadvantages compared to the SCMS as well: • An attacker that gained control over a single VBSS device could generate certificates without restrictions and use them to simulate multiple vehicles in the same or far away locations, which is called a Sybil attack [26]. The attacker could do that until misbehavior detection catches him, excludes his secret key from the group credentials and every device in his group has updated their group credentials. • The VBSS concept suggests splitting the Group Manager into multiple parts to separate join and opening algorithm, which requires multiple parties to collaborate for the opening algorithm and prevents a single entity within the system being able to break privacy protections. However, the Group Manager still may arbitrarily revoke a vehicle, without the misbehavior authority ever giving the order to do so, by just changing the group credentials. Contrary, the SCMS has checks and balances and multiple components which need to interact to produce information for revocation. • The VBSS optimizes over-the-air bandwidth compared to a simple group signature approach by using ECDSA to sign over-the-air messages. Nevertheless, the group signature in the certificate is still longer than the PCA signature in the SCMS: whereas the SCMS adds approximately 155 bytes for a signature plus pseudonym certificate with ECDSA signature to the 39 bytes of a BSM, the VBSS adds 322 bytes for a signature plus pseudonym certificate with group signature. That means in a VBSS system over-the-air BSMs would be about two times longer. In a system that requires devices to send BSMs with 10 Hz, even strategies like adding the full certificate only to every fifth message would result in 700 bytes/s for the SCMS, but 1034 bytes/s for the VBSS. Given there is a capacity for the communication channel, this results in a smaller maximum number of devices that could communicate to each other in close vicinity. • Hardware support for group signatures: There are HSMs with application- specific integrated circuit chips available to meet automotive requirements and generate at least 10 ECDSA signatures/sec and 2000 ECDSA verifications/sec and more, but there is no such hardware support for group signatures yet, resulting in higher costs per device. • At the time of writing, group signatures are studied intensively in academia but are still missing support by industry and suppliers. Conclusions In this chapter, we introduced a Security Credential Management System for V2X communications. We explained which requirements such a system has to fulfill and how the presented concept fulfills them. We showed how the SCMS manages the balance between privacy and security, and we explained how its unique design features targeting high-efficiency work. Finally, we reviewed existing alternatives
114 B. Brecht and T. Hehn and pointed out their strengths and weaknesses compared to the SCMS. At the time of writing, the SCMS is the only viable solution for a V2X communication system and the leading technology candidate for real-world deployment. Acknowledgements The authors of this chapter have contributed to the SCMS, but they rather see themselves as SCMS ambassadors than its inventors. The SCMS is a culmination of efforts by many parties and people. This includes members of the US Department of Transportation (USDOT), the Crash Avoidance Metric Partnership Vehicle Safety Consortium (CAMP) and the Vehicle Infrastructure Integration Consortium (VIIC). Its primary designer is the Vehicle Communications Security Team at CAMP, which mainly consists of representatives of vehicle manufacturers and security experts from industry and academia. References 1. Bißmeyer, N. et al., 2011. A generic public key infrastructure for securing car-to-x communi- cation. s.l., s.n. 2. ETSI, 2010a. TR 102 893 V1.1.1 (2010-03) Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis (TVRA), s.l.: s.n. 3. ETSI, 2010b. TS 102 731V1.1.1 (2010-09) Intelligent Transport Systems (ITS); Security; Security Services and Architecture., s.l.: s.n. 4. ETSI, 2012. TS 102 867 v1.1.1 (2012-06) Intelligent Transportation Systems (ITS); Security; Stage 3 mapping for IEEE 1609.2., s.l.: s.n. 5. IEEE Vehicular Technology Society, 2013. 1609.2. Annex E.4.1: Why sign data instead of using a message authentication code?, s.l.: s.n. 6. Kung, A., 2008. Secure Vehicle Communication. Security Architecture and Mechanisms for V2V/V2I., s.l.: s.n. 7. USDOT, 2006. Vehicle Safety Communications Project. Final Report 2006. Appendix H, s.l.: U.S. Department of Transportation, National Highway Traffic Safety Administration. 8. Brecht, B. et al., 2018. A Security Credential Management System for V2X Communications. IEEE Transactions on Intelligent Transport Systems. 9. Whyte, W., Weimerskirch, A., Kumar, V. & Hehn, T., 2013. A security credential management system for V2V communications. s.l., s.n., pp. 1–8. 10. USDOT, U. S. D. o. T. -. I. J. P. O., 2016. Connected Vehicle Pilot Deployment Program. [Online] Available at: https://www.its.dot.gov/pilots/ [Accessed 16 October 2017]. 11. Saltzer, J. H. & Schroeder, M. D., 1975. The Protection of Information in Computer Systems. Proceedings of the IEEE 63, September, 63(9), pp. 1278–1308. 12. Cavoukian, A., 2011. Privacy by Design. The 7 Foundational Principles., s.l.: s.n. 13. Dierks, T. & Rescorla, E., 2008. RFC 5246 - The Transport Layer Security (TLS) Protocol, s.l.: IETF - Network Working Group. 14. IEEE, 2016. IEEE Std 1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments–Security Services for Applications and Management Messages, s.l.: IEEE. 15. Chaum, D. & Van Heyst, E., 1991. Group Signatures. s.l., Springer, pp. 257–265. 16. Manulis, M. et al., 2012. Group Signatures: Authentication with Privacy, s.l.: s.n. 17. Carter, J. & Zhang, J., 2015. Analysis of Vehicle-Based Security Operations. Gothenburg, Sweden, s.n. 18. Boneh, D., Boyen, X. & Shacham, H., 2004. Short Group Signatures. s.l., Springer, pp. 41–55. 19. Calandriello, G., Papdimimitratos, P., Hubaux, J.-P. & Lioy, A., 2011. On the Performance of Secure Vehicular Communication Systems. s.l., IEEE, pp. 898–912. 20. Malina, L. et al., 2015. Efficient group signatures for privacy-preserving vehicular networks. Telecommunication Systems, 58(4), pp. 293–311.
A Security Credential Management System for V2X Communications 115 21. Carter, J. & Paul, N., 2016. Towards a Scalable Group Vehicle-based Security System. Ann Arbor, MI, USA, s.n. 22. Ateniese, G., Song, D. & Tsudik, G., 2003. Quasi-Efficient Revocation of Group Signatures. s.l., Springer, pp. 183–197. 23. Boneh, D. & Shacham, H., 2004. Group Signatures with Verifier-Local Revocation. s.l., ACM, pp. 168–177. 24. Camenisch, J. & Lysyanskaya, A., 2001. Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials. s.l., Springer, pp. 257–265. 25. Nakanishi, T. & Funabiki, N., 2005. A Short Verifier-Local Revocation Group Signature Scheme with Backward Unlinkability from Bilinear Maps. s.l., Springer, pp. 533–548. 26. Douceur, J. R., 2002. The Sybil Attack. London, UK, UK, Springer-Verlag, pp. 251–260.
V2V Vehicle Safety Communication Shubham Shrivastava Introduction National Highway Traffic Safety Administration (NTHSA) has been interested in vehicle-to-vehicle (V2V) communication as the next step in addressing grooving rates of fatalities from vehicle related crashes. Today’s crash avoidance technologies depend on on-board sensors like camera and radar to provide awareness input to the safety applications. These applications warn the driver of imminent danger or sometimes even act on the driver’s behalf. However, even technologies like those cannot “predict” a crash that might happen because of a vehicle which is not very close or not in the line of sight to the host vehicle. A technology that can “see” through another vehicle or obstacles like buildings and predict a danger can fill these gaps and reduce crashes drastically. V2V communications can provide vehicles the ability to talk to each other and therefore see around corners and through the obstacles over a longer distance compared to the current on-board sensors. It is estimated that V2X communications address up to 80% of the unimpaired crashes [1]. By means of Notice of Proposed Rulemaking (NPRM), NHTSA is working towards standardization of V2V communications and potentially mandating the broadcast of vehicle data (e.g. GPS coordinates, speed, acceleration) over DSRC through V2V. A vehicle needs an On-Board Unit (OBU) to establish the V2V communication with other vehicles also equipped with OBUs or V2I communication with the traffic infrastructure equipped with Road-Side Units (RSUs). In general, an OBU has a DSRC radio for transmission and reception, GNSS receiver, a processor, and several interfaces (e.g. CAN, Ethernet, GPS) for obtaining the vehicle data. Essential S. Shrivastava ( ) ADAS & Autonomous Driving R&D, Renesas Electronics America, Inc., Farmington Hills, MI, USA e-mail: [email protected] © Springer Nature Switzerland AG 2019 117 R. Miucic (ed.), Connected Vehicles, Wireless Networks, https://doi.org/10.1007/978-3-319-94785-3_5
118 S. Shrivastava message in V2V communication is called Basic Safety Messages (BSM). BSM is a broadcast message typically transmitted frequently up to ten times a second. Content of BSM includes vehicle information such as vehicle speed, location, and brake status. Safety applications use the remote vehicles (RVs) data from BSM and Host Vehicle (HV) data from the OBU interfaces like CAN and GNSS to predict a potential crash and alert the driver. V2V messages could also potentially be fused with on-board sensors like Radar, Lidar, and Camera to improve the confidence level of vehicle detection for safety applications or even for autonomous driving to some extent. It is important to understand that V2V can avoid only the crashes involving more than one vehicle. The primary motivation behind mandating the use of V2V based technology is the number of crashes estimated by NHTSA that can be avoided by this technology. Sixty two percent of all the crashes (approximately 3.4 million) are light-vehicle to light-vehicle crashes. The economic and comprehensive costs for these crashes amount to approximately $109 billion and $319 billion, respectively [1]. NHTSA has performed analysis using data from 2010 through 2013 and came up with top ten pre-crash scenarios (listed in Table 1) that can be addressed by V2V. It was then determined that these ten scenarios could be addressed by the following six safety applications [14]: (1) Forward Collision Warning (FCW), (2) Electronic Emergency Brake Light (EEBL), (3) Intersection Move Assist (IMA), (4) Do Not Pass Warning (DNPW), (5) Blind Spot Warning/Lane Change Warning (BSW/LCW), and (6) Left Turn Assist (LTA). These applications proved to mitigate and prevent potential crashes in the Connected Vehicle Safety Pilot Deployment Table 1 Safety applications associated with pre-crash scenarios Pre-crash scenarios Pre-crash group Associated safety application Lead vehicle stopped Rear-end Forward collision warning Lead vehicle moving Rear-end Forward collision warning Lead vehicle decelerating Rear-end Forward collision warning/emergency electronic Straight crossing path without Junction crossing brake light traffic light Intersection movement assist Left turn at crossing Left-turn across path/opposite Left turn assist direction Opposite direction Do not pass warning Opposite direction/no Opposite direction maneuver Lane change Do not pass warning Blind spot warning/lane change Opposite direction/maneuver warning Blind spot warning/lane change Change lane/same direction warning Blind spot warning/lane change Turning/same direction Lane change warning Drifting/same direction Lane change
V2V Vehicle Safety Communication 119 Program conducted by University of Michigan Transportation Research Institute (UMTRI). NHTSA’s V2V NPRM National Highway Traffic Safety Administration (NHTSA) has proposed to mandate V2V communications for new light vehicles utilizing the Dedicated Short-Range Communications (DSRC) and to standardize the messages such as Basic Safety Message (BSM) as defined in [2]. Standardizing the format of V2V messages will ensure that all the vehicles speak a “common language” and will enable the vehicle manufacturers to develop safety applications. This will have a great impact on reducing the number of crashes and fatalities. Transmission Requirements For V2V devices to be able to prevent crashes, they should be capable of broadcast- ing V2V messages in an interoperable manner. To ensure interoperability, NHTSA has proposed performance requirements for DSRC-based V2V communication and are summarized below (Tables 2, 3, and 4 referenced from [1]). Table 2 DSRC transmission range and reliability Items Description Longitudinal/lateral range Elevation transmission performance – Minimum 300 m transmission range – Transmission in all directions (360◦) Packet error rate (PER) – Elevation angle +10◦ to −6◦ Antenna location on the vehicle, Antenna polarization, and Transmit power – Less than 10% – Appropriate enough to meet the range requirements Table 3 Channel and data rate Items Description Channel usage Required data rate – Basic safety messages transmission on channel 172 Recommended alternate data rates – Devices are required at 6 Mbps – Channel busy ratio below 50%: 9 Mbps – Channel busy radio above 50%: 18 Mbps until the channel busy ratio falls below 20%
120 S. Shrivastava Table 4 Other aspects of DSRC transmission performance Items Description Age of BSM transmission – DE_DSecond shall be accurate to within 1 ms of the (monitored by the data corresponding UTC time element, DE_DSecond within the BSM) – DE_DSecond shall have a value less than 150 ms from the UTC time at which the BSM is transmitted Transmission frequency – 10 times per second under non-congested conditions V2V Basic Safety Message (BSM) Content The content of a BSM needs to be well defined to ensure that the application designers know the exact set of information that will be available, their unit, and the level of accuracy that each information element will have. SAE J2735 standard [2] specifies a message set, its data frames and data elements to support interoperability among DSRC applications. The Abstract Syntax Notation One (ASN.1) representation of a BasicSafetyMessage as defined in SAE J2735 Standard is shown below. BasicSafetyMessage ::= SEQUENCE { -- Part I, Sent at all times with each message coreDataBSMcoreData, -- Part II Content partII SEQUENCE (SIZE(1..8)) OF PartIIcontent{{ BSMpartIIExtension }} OPTIONAL, regional SEQUENCE (SIZE(1..4)) OF RegionalExtension {{REGION.Reg-BasicSafetyMessage}} OPTIONAL, ... } Part I data of the BSM (BSM Core Data) is included in every message and transmitted at all time. ASN.1 representation of the Part I data is shown below. Part II data are optional and are included in the BSM as needed. BSMcoreData ::= SEQUENCE { msgCntMsgCount, id TemporaryID, secMarkDSecond, lat Latitude, long Longitude, elev Elevation, accuracy PositionalAccuracy, transmission TransmissionState, speed Speed, heading Heading, angle SteeringWheelAngle, accelSet AccelerationSet4Way, brakes BrakeSystemStatus, size VehicleSize } -- BSM Part II content support PARTII-EXT-ID-AND-TYPE ::= CLASS {
V2V Vehicle Safety Communication 121 &id PartII-Id UNIQUE, &Type } WITH SYNTAX {&Type IDENTIFIED BY &id} PartIIcontent { PARTII-EXT-ID-AND-TYPE: Set} ::= SEQUENCE { partII-Id PARTII-EXT-ID-AND-TYPE.&id( {Set} ), partII-Value PARTII-EXT-ID-AND-TYPE.&Type( {Set}{@partII-Id} ) } PartII-Id ::= INTEGER (0..63) vehicleSafetyExtPartII-Id::= 0 -- VehicleSafetyExtensions specialVehicleExtPartII-Id::= 1 -- SpecialVehicleExtensions supplementalVehicleExtPartII-Id::= 2 -- SupplementalVehicleExtensions -- NOTE: new registered Part II content IDs will be denoted here -- In a given message there may be multiple extensions present -- but at most one instance of each extension type. BSMpartIIExtension PARTII-EXT-ID-AND-TYPE ::= { { VehicleSafetyExtensions IDENTIFIED BY vehicleSafetyExt} | { SpecialVehicleExtensions IDENTIFIED BY specialVehicleExt} | { SupplementalVehicleExtensions IDENTIFIED BY supplementalVehicleExt} , ... } Detailed information on each of the data elements above can be found in [2]. Few key BSM content requirements are given below. Data elements Requirement Time (DSecond) Milliseconds within a minute (UTC Standard)—Within ±1 ms of the actual time Position (longitude and Longitude and latitude within 1.5 m of actual position at HDOP <5 latitude) and 1 sigma absolute error Position (elevation) Within 3 m (10 feet) of actual position Speed Accurate within 0.28 m/s (1 kph) Heading For speed >12.5 m/s, accuracy within 2◦ For speed <12.5 m/s, accuracy within 3◦ AccelerationSet4Way Longitudinal & Lateral accuracy 0.3 m/s2 (long and lat Vertical accuracy 1 m/s acceleration) AccelerationSet4Way Accuracy within 0.5◦/s (YawRate) SteeringWheelAngle Report the direction of steering wheel angle within 5◦ of actual steering wheel angle VehicleSize Vehicle length and width within 0.2 m tolerance VehicleSafety Exten- Provides concise representation of vehicles recent movements with sions(PathHistory) accuracy of min 23 points and required to be transmitted with BSM Vehicle Safety Perpendicular distance—1 m; radius error—2%; transmission time Extension 4s (PathPrediction)
122 S. Shrivastava Security and Privacy in V2V Communication There are multiple security and privacy challenges that need to be addressed for V2V communication. Misbehaviors [3] are highly likely to arise in the future. Hackers can send wrong information in the vehicular network to affect the behavior of other drivers. They can also pretend to be other vehicles by using false identity. Another way hackers can attack the network is by channel jamming and aggressive injection of dummy messages [4]. It is critically important for the safety applications to have accurate information to predict a possibility of a collision. Inaccurate information might trigger false warnings and can worsen the driver’s confidence in the warning system. Moreover, false warnings might increase the safety risks. Privacy is another issue that needs to be addressed. Vehicles broadcast information such as their current location, heading, and speed. Such information should not be linked to the vehicle identification so that privacy remains protected. NHTSA has proposed the use of Public Key Infrastructure (PKI) approach for message authentication. This approach is based on a Security Credential Management System (SCMS) that uses PKI digital signatures to sign and verify basic safety messages. Sending devices sign the BSMs to authenticate themselves as accurate source of information. Receiving devices on the other hand verifies the BSMs to make sure they were sent by an authenticated source. For the signature, sending device uses a combination of the message content, timestamp, and a private key to generate the signature by first creating a hash of the message content and timestamp and then encoding them using Elliptical Curve Digital Signature Algorithm (ECDSA). The device also attaches the public key corresponding to the private key used to sign the message, the validity period of the signature, and the signature from the Pseudonym Certificate Authority (PCA). The signature of the PCA from SCMS called pseudonym certificate allows message receivers to verify that the sender was authorized to send a BSM. The receiver also needs to verify that the pseudonym certificate is not listed in the Certificate Revocation List (CRL) [5]. DSRC Protocol Stack and Underlying Standards Figure 1 illustrates the DSRC protocol stack and related standards. The standards define how data is communicated and interpreted from one V2V device to another device. Bottom to top, the DSRC protocol stack starts at the DSRC Radio level and indicates how the raw data is transmitted over the V2V wireless network. This layer also provides the received raw information to the next layer, which then organizes the data packets into network frames. These two layers are covered by IEEE 802.11p. IEEE 1609 WAVE stack builds on IEEE 802.11p and defines the higher layer standards.
V2V Vehicle Safety Communication 123 Fig. 1 DSRC protocol stack The underlying standards that provide the foundations of DSRC based Vehicle Safety are described briefly below: IEEE 1609.0: Guide for Wireless Access in Vehicular Environments (WAVE) Architecture IEEE 1609.0 standard is an architecture guide. It describes the full set of 1609 standards and their relationships to each other and other relevant standards like IEEE 802.11p, SAE J2735. This guide describes how the set of 1609 standards should work together. It also provides the guidance on the protocol architecture, interfaces, spectrum allocation, and device roles [6]. IEEE 1609.2: Security Services for Applications and Management Messages The safety applications are based on the V2V messages exchanged and hence it is very critical to protect these messages from attacks such as eavesdropping, spoofing, alteration, and replay. This standard defines secure message formats and processing. It also defines the circumstances for using unsecure message exchanges and how those messages should be processed based upon the purpose of the exchange [3].
124 S. Shrivastava IEEE 1609.3: Network Services This standard defines network and transport layer services, including addressing and routing. It specifies how various message types (e.g., WAVE Short Messages, WAVE Service Advertisements, and WAVE Routing Advertisements) are assembled, pack- aged, and handled between an application and IEEE 1609.4 for transmission or upon reception. It also describes how to build, route, process, and interpret WAVE low latency messages, as well as messages based on other well-known protocols such as the User Datagram Protocol (UDP) and Internet Protocol Version 6 (IPv6) [7]. IEEE 1609.4: Multi-Channel Operations This standard describes multi-channel radio operations for WAVE. It describes how to implement functions such as user priority access to the media, routing data packets on the correct channel with the desired transmission parameters, and the ability to coordinate switching between the control channel and service channels [8]. IEEE 1609.12: Identifier Allocations This standard describes the format and use of the provider service identifier (PSID), and indicates identifier values that have been allocated for use by WAVE systems [9]. IEEE 802.11p: Medium Access Control and Physical Layer Specifications for WAVE This standard defines enhancements to 802.11 required to support V2V safety applications. It specifies the physical layer for implementing DSRC operating at 5.9 GHz. For V2V applications, exchange of information between vehicles travelling at high speed needs to be considered. To accommodate for the rapid exchange of information between vehicles, IEEE 802.11p is an amendment to 802.11 to enable operation without setting up a basic service set [10]. SAE J2735: DSRC Message Set Dictionary SAE J2735Standard specifies message sets, data frames, and data elements, specif- ically for use by applications intended to utilize the 5.9 GHz DSRC for WAVE communications systems. The purpose of this standard is to support interoperability among DSRC applications [2].
V2V Vehicle Safety Communication 125 SAE J2945/1: On-Board System Requirements for V2V Safety Communications This standard specifies the system requirements for an on-board vehicle-to-vehicle (V2V) safety communications system for light vehicles, including standards pro- files, functional requirements, and performance requirements. It addresses the on-board system needs for ensuring that the exchange of BSMs in V2V safety communications provides the desired interoperability and data integrity to support the performance of the envisioned safety applications [11]. System Architecture Figure 2 shows the system architecture of a typical DSRC based V2V On-Board System. At minimum, the hardware includes a processor, a DSRC radio for the Fig. 2 DSRC based V2V on-board system architecture
126 S. Shrivastava transmission and reception of V2V messages, a GPS module for the reception of location information, and few peripherals and interfaces for supporting the entire system. On-Board Unit uses CAN modules to bring in vehicle data such as speed, yaw rate, and steering-wheel angle. Hardware Security Module (HSM) is another important module OBU needs to have for managing a vehicle’s security certificates and guarding against equipment tampering and bus probing. Some of the GPS units have an Inertial Management Unit (IMU) integrated or an interface to connect an IMU and can provide information like velocity, roll, pitch, and heading. The Board Support Package (BSP) is the software responsible for hardware specific operations required to get the OS up and running. The BSP and drivers provide support for the hardware components and a way for the Middleware Stack to access them. Middleware Stack takes care of the upper layer standards to provide message encoding and decoding, signing and verifying BSMs, network and transport services and so on. It provides the data from received V2V message to the application layer in a way that can be understood by an application developer. It also provides Application Program Interfaces (API) to the application layer for using the lower layer services and makes it easier and straightforward for an application engineer to do the development. Program Flow and Required Components for V2V Safety Applications Figure 3 shows a typical program flow at the application layer for the implementa- tion of V2V Safety applications. It shows two major processes in a multithreaded environment. For broadcasting a BSM, DSRC stacks might either provide a handle to a callback function every 100 ms (or the time duration specified between two BSMs) or a timer can be setup that expires every 100 ms and calls a function. The Host Vehicle data can then be retrieved from interfaces like GPS and CAN (The values of some data elements like Path History (PH) need to be calculated). Once all the data is available, the Basic Safety Message is constructed in accordance to [2]. The message is then encoded at each layer before being transmitted over DSRC by the stack based on the ASN.1 packet encoding rules [12] specified by the standards (For example—SAE J2735 specifies UPER ASN encoding of the payload). The other part of the program flow shown in Fig. 3 takes care of the received BSM and determination of collision possibility. The DSRC software stack provides a callback function that is executed every time a BSM is received. The stack also makes a structure containing all the BSM data elements corresponding to the Remote Vehicle (RV) available for use by the application developer. Host vehicle (HV) data can be obtained from interfaces on-board like GPS and CAN. The algorithms to detect a possibility of collision can be executed once the Host Vehicle and Remote Vehicle data is available. One of the major required components for any safety application is Target Classification which basically classifies the
V2V Vehicle Safety Communication 127 Fig. 3 V2V safety applications program flow position and orientation of Remote Vehicle relative to the Host Vehicle. Target Classification would further need to perform some operations like Path Prediction Radius Calculation and Path Prediction Confidence Calculations. Path History can also be used to improve the Target Classification since an extrapolation of the past maneuver can provide prediction for future maneuvers with some confidence. Based on the Remote Vehicle relative zone and direction of travel, the relevant safety applications may be executed (e.g. If the Remote Vehicle relative zone is “Ahead Left” and relative direction is “Reverse”, then the only safety applications that would be relevant are Do Not Pass Warning (DNPW) and Left Turn Assist (LTA)). Once we have result from all the safety applications, the highest priority warning can be provided to the driver on User Interface (e.g. Forward Collision Warning (FCW) will have a higher priority than Emergency Electronic Brake Light (EEBL) because FCW has a lower time-to-collision). Path History Path History (PH) represents the HV actual path with a set of concise data elements. The concise data elements are a sampled subset of the actual elements which are selected such that the perpendicular distance between any point on the actual vehicle path and the chord connecting two concise points is less than a calibration parameter
128 S. Shrivastava Vehicle Actual Path and Concise Path History Data Elements 42.4895 42.4894 42.4893 42.4892 Latitude 42.4891 42.489 42.4889 42.4888 -83.499 Vehicle Actual Path Concise Path History 42.4887 -83.4991 -83.4989 -83.4989 -83.4989 -83.4988 -83.4988 Longitude Fig. 4 Vehicle actual path and concise path history data elements (1 m). The size of the buffer containing the concise data elements is such that the represented PH distance computed using the elements of the buffer is at least a certain minimum length defined by another calibration parameter (300 m) [1]. The standard SAE J2945/1 specifies three methods for computing the concise path history points. Figure 4 shows a plot of actual vehicle path and the concise path history data elements taking up to 300 actual vehicle data elements in the buffer for computation. Host Vehicle Path Prediction (HVPP) Path Prediction is a way to determine where the vehicle is headed. Predicting the future trajectories of Host Vehicle can be very useful for classifying the relative position of Remote Vehicles. The trajectory can be represented as a circle of radius, R, and an origin located at (0, R). The radius, R is positive for curvatures to the right from the transmitting vehicle’s perspective. A radius value of 32,767 is interpreted as a straight path. It is possible to estimate the future trajectories from vehicle dynamics. The radius of curvature can be computed based on the HV speed and the rate of change of heading (yaw rate). This curvature can then be extrapolated forward to provide an
V2V Vehicle Safety Communication 129 estimate of the likely future path of the vehicle. Sign of the radius is positive if vehicle is moving in clockwise direction and negative if vehicle is moving in anti- clockwise direction. Vehicle radius can be calculated using the basic formula: radius (m) = vehicle speed (m/s) /yaw rate (radians/s) (1) Radius of curvature calculation will be influenced by road, sensor, and driver noise (in-lane wandering). These noises need to be filtered out before the radius can be used by any application. The reciprocal of radius is calculated before passing the signal as an input to a discretized second-order low pass filter. curvature (1/m) = 1/radius (2) The radius is assumed to have a value of 36,767 m (Straight Road) if either the vehicle speed is less than a calibrated threshold (1 m/s) or if the calculated radius is greater than a calibrated threshold (2500 m). Also, care should be taken to avoid divide-by-zero condition during these computations. Once the curvature is filtered-out, radius can be obtained by taking the reciprocal again. Some of the calibration parameters for the discretized second-order low-pass filter are given in Table 5. Another important parameter to be calculated is Vehicle Predicted Path Con- fidence which is used to determine if the Host Vehicle is in the “steady state” conditions. The confidence indicator is calibrated to report low confidence when large changes in the vehicle yaw rate are detected over a short period of time. These conditions may include events like lane changes, curve entry or exit, curve transition, and obstacle avoidance. The confidence value can be computed by monitoring the rate of change of the host vehicle yaw rate. The host vehicle yaw rate is fed to a discretized second-order low-pass filter with differentiator and its output is compared against a look up table which maps them to a percentage of confidence. SAE J2945/1 defines a Confidence Lookup Table that outputs a confidence from 0% to 100% by looking at the output of the filter (degrees/s2). Table 6 shows some of the calibration parameters for the discretized second-order low-pass filter with differentiator used for confidence calculation and Table 7 shows Confidence Lookup Table. Table 5 Calibration parameters for the discretized second-order low-pass filter Filter calibration parameters Default value Curvature cut-off frequency 0.33 Hz Curvature damping factor 1 Curvature sampling period 100 ms
130 S. Shrivastava Table 6 Calibration Filter calibration parameters Default value parameters for the discretized Confidence cut-off frequency 1 Hz second-order low-pass filter Confidence damping factor 1 with differentiator Confidence sampling period 100 ms Table 7 Confidence lookup table 25 20 15 10 5 2.5 2 1.5 1 0.5 0 0 10 20 30 40 50 60 70 80 90 100 Input: filtered/differentiated yaw rate (degrees/s2) Output: confidence (%) Fig. 5 RV position (Zone) relative to the HV Target Classification (TC) Target Classification provides a 360◦, relative lane-level classification of the loca- tions and direction of travel of communicating Remote Vehicle’s relative to Host Vehicle. Output of the TC module include relative position, relative direction of travel, lateral offset, longitude offset, and delta heading. It uses vehicle information like latitude, longitude, elevation, speed, heading, yaw rate, path history, and path prediction objects from the Basic Safety Message (BSM). Figure 5 shows the RV Zones relative to the HV. The TC module can classify the RV position as one of the 14 zones shown in Fig. 5. The module also provides relative RV direction of travel as one of the four possible directions shown in Fig. 6.
V2V Vehicle Safety Communication 131 Fig. 6 RV direction of travel relative to the HV Based on the relative zones and direction obtained from the TC module, relevant safety applications are executed and their outputs are monitored. The warning from highest priority safety application is then presented to the driver over an HMI. Figure 7 shows the relevant Safety Application for various relative zone and direction obtained from the TC module. Lateral and Longitudinal Offset Computation Figure 8 shows the terminologies involved in Target Classification. It shows the terminologies used and relationship between them for the computation of lateral offset and longitudinal offset between HV and RV. Some of the modules required for the development of Target Classifications are given below. Implementation of these modules are not covered in this chapter. convertLatLongToXY (refLat, refLong, refHead, latitude, longitude) (3) – Converts the GPS latitude and longitude to X and Y in meters relative to the reference latitude (refLat), reference longitude (refLat), and reference heading (refHead). convertXYtoLatLong (refLat, refLong, refHead, relX, relY) (4) – Converts X (relX) and Y (relY) in meters relative to the reference latitude (refLat), reference longitude (refLong), and reference heading (refHead) to an absolute latitude and longitude.
132 S. Shrivastava Fig. 7 Mapping of safety applications to the output of TC module (5) calcGpsDist (refLat, refLong, latitude, longitude) – Calculates the absolute distance in meters between two GPS positions (refLat, refLong) and (latitude, longitude). These components can be helpful for various computations during the develop- ment of Target Classification and Safety Applications. Each term used in Fig. 8 are explained below:
V2V Vehicle Safety Communication 133 Fig. 8 Terminologies involved in target classification hv : Host Vehicle rv : Remote Vehicle [hv_lat, hv_lon] : GPS Coordinates of the Host Vehicle [rv_lat, rv_lon] : GPS Coordinate of the Remote Vehicle hvppr : Host Vehicle Path Prediction Radius hvppc : Host Vehicle Path Prediction Center (0, hvppr) : Cartesian coordinate of the hvppc [hvppc_lat, hvppc_lon] : GPS Coordinate of the hvppc hvppc_rv_dist : Distance between hvppc and rv Angle (hv_hvppc_rv) : Angle between HV, hvppc, and RV lat_offset : Lateral offset between the HV Predicted Path and RV lon_offset : Longitudinal offset between the HV and RV along the HV Predicted Path (6)
134 S. Shrivastava Host Vehicle Path Prediction provides the Path Prediction Radius for predicted future path of the HV. Path Prediction Centre would then be at the Cartesian Coordinates (0, hvppr). The absolute GPS coordinate of the path prediction center can then be obtained using convertXYtoLatLong module as shown in Eq. (7). hvppc_lat, hvppc_lon = convertXYtoLatLong (hv_lat, hv_lon, hv_head, 0, hvppr) (7) where, hv_head = HV heading in degrees Lateral offset between the Host Vehicle Predicted Path and the RV (lat_offset) is simply the difference between hvppc_rv_dist and hvppr, where the hvppc_rv_dist can be calculated as shown in Eq. (8). hvppc_rv_dist = calcGpsDist (hvppc_lat, hvppc_lon, rv_lat, rv_lon) (8) Longitudinal offset is the Arc Length between HV and RV along the Host Vehicle Predicted Path with the center being hvppc and can be calculated as shown in Eq. (9). lon_offset = (hvppr∗) × Angle (hv_hvppc_rv) (9) In practice longitudinal distance can be approximated by adding all path history points from the vehicle in front that are ahead of the vehicle calculating longitudinal distance (e.g. host vehicle from Fig. 8). RV position relative to the HV in Cartesian coordinate system can be given as (rvRelX, rvRelY) and can be calculated as shown in Eq. (10). [rvRelX, rvRelY] =convertLatLongToXY (hv_lat, hv_lon, hv_head, rv_lat, rv_lon) (10) where, hv_head = HV heading in degrees RV Zone Classification Relative to the HV RV zones can be classified relative to the HV based on whether the RV is ahead or behind of the HV (i.e. sign of rvRelX), sign of hvppr, and lat_offset as shown in Table 8.
V2V Vehicle Safety Communication 135 Table 8 RV zones relative to the HV rvRelX hvppr lat_offset Zone ≥ 0? ≥ 0? Yes Yes lat_offset ≤ −2.5 × lanewidth Ahead Far Far Left Yes Yes Yes Yes −2.5 × lanewidth > lat_offset ≤ −1.5 × lanewidth Ahead Far Left Yes Yes Yes Yes −1.5 × lanewidth > lat_offset ≤ −0.5 × lanewidth Ahead Left Yes Yes Yes Yes −0.5 × lanewidth ≥ lat_offset ≤ −0.5 × lanewidth Ahead Yes No Yes No 0.5 × lanewidth ≥ lat_offset < 1.5 × lanewidth Ahead Right Yes No Yes No 1.5 × lanewidth ≥ lat_offset < 2.5 × lanewidth Ahead Far Right Yes No Yes No Lat_offset ≥ 2.5 × lanewidth Ahead Far Far Right Yes No No Yes lat_offset ≤ −2.5 × lanewidth Ahead Far Far Right No Yes No Yes −2.5 × lanewidth > lat_offset ≤ −1.5 × lanewidth Ahead Far Right No Yes No Yes −1.5 × lanewidth > lat_offset ≤ −0.5 × lanewidth Ahead Right No Yes No Yes −0.5 × lanewidth ≥ lat_offset ≤ −0.5 × lanewidth Ahead No No No No 0.5 × lanewidth ≥ lat_offset < 1.5 × lanewidth Ahead Left No No No No 1.5 × lanewidth ≥ lat_offset < 2.5 × lanewidth Ahead Far Left No No No No Lat_offset ≥ 2.5 × lanewidth Ahead Far Far Left No No lat_offset ≤ −2.5 × lanewidth Behind Far Far Left −2.5 × lanewidth > lat_offset ≤ −1.5 × lanewidth Behind Far Left −1.5 × lanewidth > lat_offset ≤ −0.5 × lanewidth Behind Left −0.5 × lanewidth ≥ lat_offset ≤ −0.5 × lanewidth Behind 0.5 × lanewidth ≥ lat_offset < 1.5 × lanewidth Behind Right 1.5 × lanewidth ≥ lat_offset < 2.5 × lanewidth Behind Far Right Lat_offset ≥ 2.5 × lanewidth Behind Far Far Right lat_offset ≤ −2.5 × lanewidth Behind Far Far Right −2.5 × lanewidth > lat_offset ≤ −1.5 × lanewidth Behind Far Right −1.5 × lanewidth > lat_offset ≤ −0.5 × lanewidth Behind Right −0.5 × lanewidth ≥ lat_offset ≤ −0.5 × lanewidth Behind 0.5 × lanewidth ≥ lat_offset < 1.5 × lanewidth Behind Left 1.5 × lanewidth ≥ lat_offset < 2.5 × lanewidth Behind Far Left Lat_offset ≥ 2.5 × lanewidth Behind Far Far Left Predicted Delta Heading and Classification of RV Direction of Travel Relative to the HV In Fig. 9, θ1 is the vehicle heading for HV and θ2 is the vehicle heading for RV. Please note that the vehicle heading is given relative to absolute north; clockwise being positive and anti-clockwise being negative. The absolute heading difference (delta heading) between HV and RV is given as: θ = θ1 − θ2 (11) However, looking at the track HV and RV are driving on, one would expect the delta heading to be close to zero since both the HV and RV are on the same
136 S. Shrivastava Fig. 9 Absolute delta heading and predicted delta heading computation route. The delta heading can be predicted to be very close to accurate based on Host Vehicle Path Prediction Radius obtained from the path prediction module. If ‘R’ is the hvppc obtained from the Path Prediction module, and the vehicles are driving on the same track as shown in the figure below, then ideally the absolute delta heading ( θ) will be equal to the central angle (ϕ) between HV, hvppc, and RV. Predicted delta heading can then be given as: Predicted Delta Heading( θ ) = θ − ϕ = θ1 − θ2 − ϕ = HV Heading − RV Heading − Central Angle (12) It can be very easily proved that θ = ϕ (in Fig. 9) as shown below: For ADR in the figure above, ∠RAD + ∠ADR + ∠DRA = 180◦ (Sum of Angles of Triangles) ∠RAD + 90◦ + ϕ = 180◦ ∠RAD = 90◦ − ϕ (13) Also, for ACB in the Fig. 9, ∠BAC = ∠RAD = ◦ − ϕ (14) 90
V2V Vehicle Safety Communication 137 Table 9 Classification of RV direction of travel relative to the HV Predicted delta heading ( θ ) θ ≤ −155◦ HV to RV relative direction Equidirectional −25◦ ≤ θ ≤ 25◦ Intersecting right 25◦ < θ < 155◦ Reverse 155◦ ≤ θ ≤ 180◦ or −180◦ ≤ Intersecting left −155◦ < θ < −25◦ ∠ACB = ∠FCD = θ (Vertically Opposite Angles) (15) ∠CBA = ◦ (16) 90 ∠BAC + ∠ACB + ∠CBA = ◦ (Sum of Angles of Triangles) (17) 180 90◦ − ϕ + θ + 90◦ = 180◦ (Using (14), (15), and (16) in (17)) (18) θ=ϕ Once we have the predicted delta heading, the RV direction of travel relative to the HV can be easily classified as shown in Table 9. Improvements in Lateral Offset Computation by Using Path History Lateral offset can be fine-tuned by using the average of lateral offsets between the Host Vehicle Predicted Path and Concise Path History points. If both the HV and RV are driving steadily on the same road, then the average lateral offset will provide a stable RV zone classification. Figure 10 shows the lateral offsets between the HV Predicted Path and RV Concise Path History Points. Pseudocode to compute the average lateral offset is given below: NUM_OF_RVPH_POINTS_AHEAD_OF_HV = 0 AVG_LAT_OFFSET = 0 FOR (n = 0 to NUM_OF_PH_POINTS_AVAILABLE-1) IF RV_PH(n) AHEAD OF HV THEN COMPUTE LAT_OFFSET(n) AVG_LAT_OFFSET = AVG_LAT_OFFSET + LAT_OFFSET(n) NUM_OF_PH_POINTS_AHEAD_OF_HV = NUM_OF_PH_POINTS_AHEAD_OF_HV + 1 ELSE BREAK LOOP END IF END FOR AVG_LAT_OFFSET = AVG_LAT_OFFSET/NUM_OF_PH_POINTS_AHEAD_OF_HV
138 S. Shrivastava Fig. 10 Lateral offsets between the HV predicted path and RV concise path history points Where, LAT_OFFSET(n) is the lateral offset between the HV Predicted Path and RV Path History Point n The average lateral offset could be used to improve the target classification if any of the following is true: 1. RV is driving steadily on the same route as HV. 2. HV is not driving steadily (Path Prediction Confidence lower than a threshold). Figure 11 shows a scenario where HV and RV are driving on two different routes. Although the predicted delta heading will be close to zero, it can be determined that they are not driving on the same route by looking at the RV Path History Points as shown below.
V2V Vehicle Safety Communication 139 Fig. 11 Lateral offsets for HV and RV driving on different routes In Fig. 11: Diff1 = lat_offset0 - lat_offset1 Diff2 = lat_offset0 -lat_offset2 IF {|Diff1| < Threshold AND |Diff2| < Threshold } THEN RV is driving steadily on the same route as the HV END IF Where, Threshold is a calibration value less than the width of a lane, typically 3.7. If HV Path Prediction Confidence is lower than a calibrated threshold, that would mean that the HV is not driving steadily (e.g. a lane change). This would cause the lateral offset to drift a lot and using the average lateral offset would potentially improve the confidence in RV Zone classification.
140 S. Shrivastava Another way to improve the target classification is by performing the 2-D Position Extrapolation [11]. Position Extrapolation is a way to estimate the vehicle’s current position based on the vehicle’s last known position, heading, and speed. Position Extrapolation can be used for classifying lateral and longitudinal offsets if an update about the vehicle is not obtained in a timely manner. V2V Safety Applications Vehicle position and dynamics information like latitude, longitude, elevation, heading, speed, yaw rate etc. can be used to predict the future path of vehicles and estimate the possibility of collision in near future. The safety applications considered in this section address rear-end, opposite direction, junction crossing, and lane change crash scenarios. These scenarios can be covered by the safety applications listed in Table 1 and are described below. Forward Collision Warning (FCW) FCW warns the driver of an impending collision between the HV front-end and a RV rear-end. This collision is possible only if both the HV and RV are driving in the same direction and are on the same lane (RV could be stopped, decelerating, or moving at a speed slower than the HV). Figure 12a shows the relevant target classification zone for FCW and Fig. 12b shows a possible scenario for FCW. Fig. 12 (a) FCW target classification zones (b) An example scenario for FCW
V2V Vehicle Safety Communication 141 The output of Target Classification (TC) Module is used to determine if RV is in the same lane as the HV. TC also provides the longitudinal offset which is used along with vehicle dynamics information to determine if there is a possibility of forward collision. The simplest way to predict forward-collision is to compute the time- to-collision (TTC) and compare that with a calibrated threshold value. A simple pseudo-code for the implementation of FCW is given below: FCW_WARNING = FALSE IF ((RV_ZONE is AHEAD) AND (RV_DIRECTION is EQUIDIRECTIONAL)) THEN IF(HV_SPEED > RV_SPEED) THEN TTC = LONGITUDINAL_OFFSET/(HV_SPEED - RV_SPEED) IF(TTC < K_TTC_THRES) THEN FCW_WARNING = TRUE END IF END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module HV_SPEED: Speed of Host Vehicle RV_SPEED: Speed of Remote Vehicle LONGITUDINAL_OFFSET: Longitudinal Offset as obtained from the TC mod- ule TTC: time-to-collision K_TTC_THRES: FCW time-to-collision calibrated threshold FCW_WARNING: FALSE – No Warning; TRUE – FCW Warning Generated Electronic Emergency Brake Light (EEBL) EEBL addresses the scenario where a Remote Vehicle is ahead and in the same lane as Host Vehicle. If there are other vehicles between HV and RV considered, and the RV brakes hard, a potential crash is imminent if no brake light is visible on the vehicle in front of HV. EEBL can issue a warning to the driver of HV in such scenarios where the RV is not directly visible to the HV and thus can help avoid the crash. Figure 13a shows the relevant target classification zone for EEBL and Fig. 13b shows a possible scenario for EEBL. Once we establish that the RV is ahead in the same lane as the HV and it is driving in the same direction, RV acceleration information from the BSM can be used to determine if the RV has braked hard. EEBL warning is issued if the RV acceleration value is less than a calibrated deceleration threshold value. HV can either find this out from the acceleration value transmitted as a part of the DF_BSMcoreDataData Frame or from the eventHardBraking event flag transmitted as a part of DF_VehicleSafetyExtensionsData Frame. SAE J2735 [2] suggests that
142 S. Shrivastava Fig. 13 (a) EEBL target classification zones (b) An example scenario for EEBL the minimum acceleration threshold of the RV to trigger EEBL warning be −0.4 g (−3.92 m/s2). A simple pseudocode for the implementation of EEBL is given below: EEBL_WARNING = FALSE IF ((RV_ZONE is AHEAD) AND (RV_DIRECTION is EQUIDIRECTIONAL)) THEN IF (LONGITUDINAL_OFFSET < K_MAX_EEBL_ZONE_LEN) THEN IF ((HV_SPEED > K_HV_MIN_SPD_THRES) AND (RV_ACCEL < K_EEBL_ ACCEL_THRES)THEN EEBL_WARNING = TRUE END IF END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module HV_SPEED: Speed of Host Vehicle RV_ACCEL: Acceleration of Remote Vehicle LONGITUDINAL_OFFSET: Longitudinal Offset as obtained from the TC mod- ule K_MAX_EEBL_ZONE_LEN: Maximum longitudinal offset between HV and RV (300 m) K_HV_MIN_SPD_THRES: HV minimum speed threshold (1 m/s) K_EEBL_ACCEL_THRES: EEBL minimum acceleration threshold (−3.92 m/s2) EEBL_WARNING: FALSE – No Warning; TRUE – EEBL Warning Generated
V2V Vehicle Safety Communication 143 Fig. 14 (a) IMA target classification zones (b) An example scenario for IMA Intersection Movement Assist (IMA) IMA safety application is intended to warn the driver of HV if it is not safe for the HV to enter an intersection due to high possibility of collision with other RVs. This application estimates the time taken by the HV and RV to arrive at the intersection point and issues a warning if both vehicles are predicted to arrive at approximately the same time. Figure 14a shows the relevant target classification zone for IMA and Fig. 14b shows a possible scenario for IMA. This module can issue either “IMA Right” or “IMA Left” warning based vehicle position, speed, heading information. Target Classification Zone and Direction outputs are used to determine if a Remote Vehicle is in either IMA Right or IMA Left Zone as shown in Fig. 14a. Figure 15 shows a scenario for IMA Left and terminologies used for all the computations. In Fig. 15: lat_offset: Lateral Offset between the HV and RV as obtained by the TC module. lon_offset: Longitudinal Offset between the HV and RV as obtained by the TC module. θ: Predicted Delta Heading as obtained by the TC module. hv_to_interection_dist: Arc distance between the HV and Intersection Point B. rv_to_interection_dist: Arc distance between the RV and Intersection Point B. For ABC in the Fig. 15, BC = AC (19) BC = tlaant(_ofθ)f set tan( θ) hv_to_interection_dist can be given as the following:
144 S. Shrivastava Fig. 15 Estimation of the time taken by HV and RV to arrive at the intersection point hv_to_intersection_dist = lon_off set + BC lat_off set (20) hv_t o_i nt er s ect i on_d i s t = lon_off set + tan( θ) Similarly, rv_to_interection_dist can be given as the following: r v_t o_i nt er s ect i on_d i s t = lat_off set (21) sin ( θ) If the difference between time-taken by HV to travel hv_to_interection_dist (meters) and the time-taken by RV to travel rv_to_interection_dist (meters) is within a calibrated tolerance value then the IMA warning is issued to the driver of HV. A simple pseudo-code for the implementation of IMA is given below: IMA_LEFT_WARNING = FALSE IMA_RIGHT_WARNING = FALSE IF ((RV_DIRECTION is INTERSECTING_RIGHT) AND ((RV_ZONE is AHEAD) OR (RV_ZONE is AHEAD_RIGHT) OR (RV_ZONE is AHEAD_FAR_RIGHT) OR (RV_ZONE is AHEAD_FAR_FAR_RIGHT))) THEN HV_TO_INTERSECTION_DIST = LON_OFFSET + (LAT_OFFSET/ TAN(DELTA_HEADING)) RV_TO_INTERSECTION_DIST = LAT_OFFSET/SIN(DELTA_HEADING) HV_TTI = HV_TO_INTERECTION_DIST/HV_SPEED RV_TTI = RV_TO_INTERECTION_DIST/RV_SPEED IF((HV_TO_INTERECTION_DIST < K_MAX_HV_TO_INTERSECTION_DIST) AND
V2V Vehicle Safety Communication 145 (ABSOLUTE(HV_TTI - RV_TTI) < K_TTI_TOLERANCE)) THEN IMA_RIGHT_WARNING = TRUE END IF END IF IF ((RV_DIRECTION is INTERSECTING_LEFT) AND ((RV_ZONE is AHEAD) OR (RV_ZONE is AHEAD_LEFT) OR (RV_ZONE is AHEAD_FAR_LEFT) OR (RV_ZONE is AHEAD_FAR_FAR_LEFT))) THEN HV_TO_INTERSECTION_DIST = LON_OFFSET + (LAT_OFFSET/TAN (DELTA_HEADING)) RV_TO_INTERSECTION_DIST = LAT_OFFSET/SIN(DELTA_HEADING) HV_TTI = HV_TO_INTERECTION_DIST/HV_SPEED RV_TTI = RV_TO_INTERECTION_DIST/RV_SPEED IF((HV_TO_INTERECTION_DIST < K_MAX_HV_TO_INTERSECTION_DIST) AND (ABSOLUTE(HV_TTI - RV_TTI) < K_TTI_TOLERANCE)) THEN IMA_LEFT_WARNING = TRUE END IF END IF Where, RV_ZONE: RV relative zone as obtained from the TC module RV_DIRECTION: RV relative direction as obtained from the TC module HV_SPEED: Speed of Host Vehicle RV_SPEED: Speed of Remote Vehicle LAT_OFFSET: Lateral Offset as obtained from the TC module LON_OFFSET: Longitudinal Offset as obtained from the TC module DELTA_HEADING: Absolute Delta Heading between HV and RV in Radians HV_TO_INTERSECTION_DIST: Distance between the HV and intersection point RV_TO_INTERSECTION_DIST: Distance between the RV and intersection point HV_TTI: Time-taken by the HV to arrive at the intersection point RV_TTI: Time-taken by the RV to arrive at the intersection point K_MAX_HV_TO_INTERSECTION_DIST: Calibrated Maximum Distance between the HV and Intersection point for IMA K_TTI_TOLERANCE: Calibrated tolerance value for the difference between HV_TTI and RV_TTI ABSOLUTE(): A function that returns the absolute value IMA_RIGHT_WARNING: FALSE – No Warning; TRUE – IMA Right Warning Generated IMA_LEFT_WARNING: FALSE – No Warning; TRUE – IMA Left Warning Generated
Search
Read the Text Version
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
- 177
- 178
- 179
- 180
- 181
- 182
- 183
- 184
- 185
- 186
- 187
- 188
- 189
- 190
- 191
- 192
- 193
- 194
- 195
- 196
- 197
- 198
- 199
- 200
- 201
- 202
- 203
- 204
- 205
- 206
- 207
- 208
- 209
- 210
- 211
- 212
- 213
- 214
- 215
- 216
- 217
- 218
- 219
- 220
- 221
- 222
- 223
- 224
- 225
- 226
- 227
- 228
- 229
- 230
- 231
- 232
- 233
- 234
- 235
- 236
- 237
- 238
- 239
- 240
- 241
- 242
- 243
- 244
- 245
- 246
- 247
- 248
- 249
- 250
- 251
- 252
- 253
- 254
- 255
- 256
- 257
- 258
- 259
- 260
- 261
- 262
- 263
- 264
- 265
- 266
- 267
- 268
- 269
- 270
- 271
- 272
