400 Commonwealth Drive, Warrendale, PA 15096-0001

SURFACE VEHICLE RECOMMENDED PRACTICE

J1760

ISSUED DEC2001 2001-12

Issued

Data Security Services

ForewordThe ISO/CD 15764 Road vehicles Extended data link security International Standard requires Security Services for all data transfer between a vehicle and a diagnostic scan tool. In summary, this standard requires Authentication of the scan tool and the vehicle by a Certification Authority and all communication interchange of data to use an encryption method for every instance or session of use. The objective of this SAE J1760 Recommended Practice is to require the use of these same Security Services modified by the Class of Security required by the data to be exchanged as determined by the Resource Provider. This document requires only a one time Authentication of Security Services for the installation of an IDB Device. For a background discussion on the problem scenarios that require security, see Appendix A. TABLE OF CONTENTS 1. 1.1 1.2 1.3 1.4 1.5 1.6 2. 2.1 2.2 3. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 Scope ....................................................................................................................................................... 2 The IDB .................................................................................................................................................... 3 IDB Device ............................................................................................................................................... 3 Classes of Security................................................................................................................................... 3 Theft Deterrent ......................................................................................................................................... 3 Compatible IDB Devices........................................................................................................................... 3 Data Security Service Execution .............................................................................................................. 4 References ............................................................................................................................................... 4 Applicable Documents.............................................................................................................................. 4 Related Publications ................................................................................................................................. 4 Definitions................................................................................................................................................. 4 Access ...................................................................................................................................................... 4 Authenticated Device ............................................................................................................................... 4 Authentication ........................................................................................................................................... 4 Certification Authority ............................................................................................................................... 4 Ciphertext ................................................................................................................................................. 4 Classes of Security................................................................................................................................... 5 Decryption ................................................................................................................................................ 5 Device Resource Privileges...................................................................................................................... 5 Eavesdropping ......................................................................................................................................... 5 Encryption ................................................................................................................................................ 5 Hash Function .......................................................................................................................................... 5 IDB Device ............................................................................................................................................... 5

SAE Technical Standards Board Rules provide that: This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user. SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. TO PLACE A DOCUMENT ORDER: +1 (724) 776-4970 FAX: +1 (724) 776-0790 SAE WEB ADDRESS http://www.sae.org Copyright 2001 Society of Automotive Engineers, Inc. All rights reserved.

Printed in U.S.A.

SAE J1760 Issued DEC2001 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 4. 5. 5.1 5.2 5.3 5.4 5.5 5.6 6. 6.1 6.2 6.3 6.4 6.5 IDB Gateway.............................................................................................................................................5 Manipulation .............................................................................................................................................5 Masquerading ...........................................................................................................................................5 Passwords or PINs ................................................................................................................................... 5 Private Encryption Key .............................................................................................................................5 Private Key ...............................................................................................................................................5 Proxy.........................................................................................................................................................5 Public Encryption Key...............................................................................................................................5 Public Key .................................................................................................................................................5 Resource Provider ....................................................................................................................................5 Security Breach ........................................................................................................................................5 Security Service........................................................................................................................................5 Symmetric Key..........................................................................................................................................6 Abbreviations/Acronyms ...........................................................................................................................6 Functional Requirements ..........................................................................................................................6 Authentication ...........................................................................................................................................6 Access ......................................................................................................................................................6 Message Security .....................................................................................................................................6 Security Breach Avoidance .......................................................................................................................6 Vehicle Device Transfer............................................................................................................................6 Usability ....................................................................................................................................................7 Security Model ..........................................................................................................................................7 Security Levels of IDB Device Resources ................................................................................................7 Enabling Security......................................................................................................................................8 Disabling Security .....................................................................................................................................8 Process of authentication by Certification Authority .................................................................................8 The Process to Establish an Ability to Conduct Secured Communication on the IDB Network between Device Pairs....................................................................................................9

Appendix A Problem Scenarios that Require Security............................................................................................... 10 A.1 Background ............................................................................................................................................. 10 A.2 Need for Data Security ........................................................................................................................... 10 A.3 Assure Proper Function .......................................................................................................................... 10 A.4 Disable and discourage the use of stolen ITS modules .......................................................................... 10 1. ScopeThe scope of this SAE Recommended Practice is to require the use of the same Security Services as defined by the International Standard ISO/CD 15764, modified by the Class of Security as determined by the resource provider and referenced in Table 1, Extended Data Link Security References. TABLE 1EXTENDED DATA LINK SECURITY INTERNATIONAL STANDARD ISO/CD 15764 REFERENCES
Parameter Hashing Function Symmetric Key Public Key Private Key References ISO/IEC 9797-2 ISO/IEC 10118-3 ANSI X 9.52 ISO/IEC 11770-1 ISO/IEC 11770-3 ISO/IEC 11770-1 128 bits 1024 bits modulus 1024 bits exponent 1024 bits modulus 1024 bits exponent Values

-2-

SAE J1760 Issued DEC2001 1.1 The IDB GatewayThe IDB Gateway shall be considered an IDB Device operating on the IDB network. This SAE J1760 Data Security Services Recommended Practice defines security, when deemed necessary, between devices on the IDB, as granted by the resource providers. The Security Services required between the IDB Gateway and the vehicle are not within the scope of this document. IDB Device FunctionsThe device functions may be represented by proxy. Therefore devices such as those that are connected to the IDB may be a communication mechanism, external to the bounded vehicle communication system and shall by proxy be protected by the Authentication of Security Services required by this document. The Security Services required between the IDB network and outside the bounded vehicle communication system shall be within the scope of this document. (Reference Figure 1 for a data security services system diagram.) Classes of SecurityVarious capabilities (messages) shall be protected by different classes of security as required by 6.1. Security Services, which involve the transmission and/or reception of only Class 0 resources, are not within the scope of this document. Theft Deterrent The data security services shall provide a mechanism that will discourage the theft of IDB Devices

1.2

1.3

1.4

FIGURE 1DATA SECURITY SERVICE SYSTEM DIAGRAM 1.5 Compatible IDB Devices All IDB Devices operating on the IDB network that claim to be IDB compatible and utilize resources from an IDB compatible device shall comply with the requirements set forth in this Recommended Practice.

-3-

SAE J1760 Issued DEC2001 1.6 Data Security Service Execution This Recommended Practice defines the functional requirements for providing data security service execution with IDB Devices. The methods used in implementing these services are found in the ISO/CD 15764 Road vehicles Extended data link security International Standard. References Applicable Publications The following publications form a part of this specification to the extent specified herein. Unless otherwise indicated, the latest version of SAE publications shall apply. SAE PUBLICATIO NAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001 SAE J2355ITS Data Bus Architecture Reference Model 2.1.2 ANSI PUB LICATION Available from ANSI, 25 West 43rd Street, New York, NY 10036-8002 ANSI X9.52American National Standard for Financial ServicesTriple Data Encryption Algorithm Modes of Operation 2.1.3 ISO P UBLICATIONSAvailable from ANSI, 25 West 43rd Street, New York, NY 10036-8002. ISO/CD 15764Road vehiclesExtended data link security ISO/IEC9797-2Information technologySecurity techniquesData integrity mechanism using a cryptographic check function emplopying a block cipher algorithm ISO/IEC10118-3Information technologySecurity techniquesHash-functionsPart 3: Dedicated hash-functions ISO/IEC 11770-1Information technologySecurity techniquesKey managementPart 1: Framework ISO/IEC11770-3Information technologySecurity techniquesKey managementPart 3: Mechanisms using asymmetric techniques 2.2 Related PublicationsThe following publications are provided for information purposes only and are not a required part of this document. SAE PUBLICATIO NSAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001. SAE J2366 and all its parts SAE J2367IDB Gateway SAE J2590PMODE for In-Vehicle Networks 3. 3.1 Definitions Access The process of retrieving data from or sending to another authenticated device, such that the data and/or actions are allocated to only an authorized user or device. Authenticated Device An IDB Device that has the attribute of confirmed authorization to access secure services through a process of authentication. Authentication The process of confirming, through the utilization of a Certification Authority, that an IDB Device satisfies the requirements defined in this Recommended Practice. Certification Authority The Certification Authority is an organization that issues Public Key certificates which contain the name of a person (device manufacturer), the person's Public Key (device's Public Key), serial number, start and end date, and other information. CiphertextA disguised or encrypted file or message.

2. 2.1

2.1.1

2.2.1

3.2

3.3

3.4

3.5

-4-

SAE J1760 Issued DEC2001 3.6 3.7 3.8 Classes of SecuritySecurity classes are defined in Section 6.1 as levels of trust and authentication. Decryption Any process to convert ciphertext back to plaintext using a cryptographic algorithm. Device Resource PrivilegesAuthorization which allow IDB Device A to gain access to data within another IDB Device B or cause execution of an actuator controlled by IDB Device B on command. Eavesdropping A means by which a third party passively listens to the transfer of information between trusted electronic units in an attempt to gather knowledge.

3.9

3.10 Encryption A process to convert plaintext into ciphertext using a cryptographic algorithm. 3.11 Hash Function A mechanism for detecting alteration of a message or file enroute from the distributor to the recipient(s). 3.12 IDB Device Any ITS Data Bus (IDB) node per 6.1 or module that requires Security Services from another IDB Node or module as defined in this document. Note the IDB is not limited to copper wire physical layer interfaces. 3.13 IDB Gateway An interface between the IDB and the facilities provided by the vehicle manufacturer. 3.14 Manipulation A process by which a third party changes (corrupts) data transferred between trusted electronic units. 3.15 Masquerading A process by which a third party sends data pretending that it originates from the trusted electronic unit. 3.16 Passwords or PINs A group of characters used to access protected information, such as personal e-mail. A password or a PIN usually consists of three to ten alphanumeric characters. 3.17 Private Encryption KeyA key used for private encryption. (See Private Key) 3.18 Private Key The secret key of a public-private key cryptography system. This key is used to sign outgoing messages, and is used to decrypt incoming messages. (See Private Encryption Key) 3.19 ProxyA substitute device such as an intermediate server or other electronic device. 3.20 Public Encryption Key A key used for public encryption. (See Public Key) 3.21 Public KeyThe public key of a private-public key cryptography system. This key is used to confirm signatures on incoming messages or to encrypt a file or message so that only the holder of the Private Key can decrypt the file or message. (See Public Encryption Key) 3.22 Resource Provider The manufacturer or the representative of a IDB Device that provides Security Services to another IDB Node or module as defined in this document. 3.23 Security Breach A lapse in the ability of two trusted electronic units to securely transfer information between themselves during the authentication process, or during the normal course of transferring information. 3.24 Security Service A series of mechanisms intended to prevent or detect Security Breach in the transfer of information between two trusted electronic units. Breach attacks shall include Eavesdropping, Manipulation, and Masquerading. The services shall also discourage the theft of the IDB Device.

-5-

SAE J1760 Issued DEC2001 3.25 Symmetric Key The key that is used to encrypt a file or message is the same key that is used to decrypt the file or message after an authentication process has taken place between the two devices. 4. Abbreviations/Acronyms IDB ITS Data Bus ITS Intelligent Transportation System 5. 5.1 Functional Requirements Authentication A device attached to the IDB shall have a security mechanism to authenticate another device attached to the IDB. The Authenticated Device will then be allowed to request resources (this could be a data request or a request to execute a particular function or feature) from the other Authenticated Device. Access Authenticated Devices shall be capable of communicating the resources that an Authenticated Device is capable of using upon Authentication of that device. a. b. Authenticating Devices shall have the ability to accomplish (grant) multiple classes of security access to various devices requesting resources that the Authenticating Device controls (even through proxy). A registry of access enabled Device Resource Privileges for each security class shall be used to describe the various capabilities of each security class. Classes may range from full access of resources to no access.

5.2

5.3

Message Security The request mechanism to utilize another devices resources shall have the ability to have security features built into the requesting and response message structure (i.e., encryption). Security Breach Avoidance Devices shall not be able to breach security when they are attached in place of an active, prior authenticated, IDB Device. The security mechanism within a device shall not be able to be obtained through a physical break-in to or interrogation of that device. The security mechanism within a device shall not be able to be altered. One successful breach will not be able to be applied to subsequent breaches within the same system or other like systems. Upon three successive, unsuccessful Authentication attempts in a Certification Authority session by a device, a infinite period of no retry shall be imposed for that device. This shall not preclude the use or functionality of property functioning and authenticated devices on the IDB. The most secure Authentication requirement method shall provide a probability of, at most, one Security Breach in 100000000 breach attempts from someone reasonably knowledgeable in the art of computers/ electronics. Authenticated Devices shall have a log of breach attempts.

5.4

5.5

Vehicle Device Transfer The following requirements shall apply for the certification of one IDB compatible device in more than one vehicle, assuming that the device requires and/or delivers secured resources: AUTHORIZATION FOR VEHICLE TO VEHICLE T RANSFER The device security mechanism shall have the ability to restrict unwanted vehicle to vehicle transfer (IDB to IDB). All devices on the IDB shall be authenticated by the Certification Authority. Any transfer of devices from one vehicle to another must also undertake the authentication process. If a device is not authenticated to the other IDB Devices in the vehicle, increased security shall occur such that a non-authenticated IDB Device shall be unable to access the secured resources of other IDB Devices on the bus. The certification process is defined in 6.4. a. Authorization shall be required if a device is to be used in a temporary vehicle, such as a rental car. This authorization shall typically have a set amount of time that the authorization will last, and authorization shall expire when the time period elapses.

5.5.1

-6-

SAE J1760 Issued DEC2001 b. Authorization shall also be required when a device is to operate in more than one vehicle. This case of multiple authorization shall require all devices and vehicles slated for this multiple authorization to be presented to the Certification Authority in the same authorization session.

5.6

Usability Data security functions shall be as transparent as possible to the user. These secure devices shall have a mechanism defined to dynamically change their Security Services. All IDB diagnostic functions shall be compatible with the security mechanisms defined herein. Security ModelThe following principles shall apply: a. b. c. d. e. f. A Certification Authority shall enable secure device to device communications. Expiration of the authorization shall increase security. Authorization cancellation shall be available without involvement of the Certification Authority. The authentication process shall be encrypted. The certification algorithms shall be standard. A mechanism within the IDB Device for detecting non-authenticated devices on the IDB shall be employed. Such a detection shall increase security measures where deemed necessary.

6.

The following principles may be deployed but are not required: a. b. In addition to security mechanisms, device pairs may use passwords, or PINs. There should be security measures employed in any IDB Device that receives or transmits outside the bounded vehicle communication system through any of various methods (e.g., RF, infrared, etc.).

6.1

Security Levels of IDB Device Resources Classes of Security shall be associated with each IDB Device resource and an appropriate class assigned to each resource. The decision of security class assignment for the resources is the domain of the device resource provider. Each resource may have multiple Classes of Security assigned to it, as different levels of security may be necessary to control which resources are able to be accessed by a particular IDB Device. The following are definitions of the current levels of security for IDB Device resources: a. b. Class 0 No defined security measures are required for requesting access to a Class 0 resource. Class 1 Access to a Class 1 resource shall require that the requesting IDB Device be authenticated via the process described in 6.4. An IDB Device shall ignore all requests for access to its Class 1 resources from non-authenticated devices and shall not send messages regarding its Class 1 resources to non-authenticated devices. This class of security prevents Masquerading (third party sending data pretending that it originates from the trusted electronic unit). Detection of a Masquerading device shall result in a no response from the receiving device. No data shall be sent to a Masquerading device, nor shall commands for actuation be responded to from a Masquerading device. Also, the device receiving a data request or command from a Masquerading device shall broadcast a warning message onto the IDB regarding the attempted security breach. Class 2 Access to Class 2 resources shall adhere to the same requirements as that of a Class 1 resource and shall require that all messages regarding this class of resources be encoded with a Hash Function. When the alteration of a message or file en route from the sender to the recipient(s) has been detected, the receiving IDB Device shall ignore all requests for access to its Class 2 resources and shall not send messages regarding its Class 2 resources to that requesting device. This class of security detects manipulation of data, in which a third party changes data transferred between the trusted electronic units. Detection of a manipulated message shall result in a no response from the receiving device. No data shall be sent in response to a manipulated message, nor shall commands for actuation be responded to from a manipulated message. Also, the device receiving a data request or command from a manipulated message device shall broadcast a warning message onto the IDB regarding the attempted security breach.

6.1.1

c.

-7-

SAE J1760 Issued DEC2001 d. Class 3 Access to Class 3 resources shall adhere to the same requirements as that of a Class 1 resource and shall require that all messages regarding this class of resources be encrypted with a Symmetric Key as defined in 6.5. All requests for Class 3 resources shall be encrypted and all responses to requests for Class 3 resources shall also be encrypted. This class of security inhibits breach by Eavesdropping (a third party obtains data sent between the trusted electronic units, knowledge of which it is not entitled to possess). This type of security breach attempt is not detectable, and because it is encrypted is not relevant to the resource provider, therefore no further action is required by a sending device. Class 4 Access to a Class 4 resource shall always be denied. This means that this particular resource may be denied to a particular requesting IDB Device, but access to a different requesting IDB Device may be granted via assigning this resource to a different Class for the different IDB Device. If a device requests access to a Class 4 resource, the request shall be ignored and the receiving device of the request shall broadcast a warning message onto the IDB regarding the attempted security breach.

e.

6.2

Enabling Security Each IDB Device that requires data security services of Class 1 and higher shall have a Private Encryption Key, a Public Encryption Key and a unique identification. The device Private Key shall be installed within the device during the manufacturing process utilizing a certificate issued by a Certification Authority. The unique identification of the device with the device Public Key shall be available from the Certification Authority. The Certification Authority shall enable secure communication between device pairs. Secure encrypted communications shall occur between the Certification Authority and the device pairs utilizing Public Encryption Keys and the device Private Encryption Keys. The Certification Authority and the device pairs shall establish a Symmetric Key using the key exchange algorithm mechanism. A standard security algorithm shall be used in all devices for secure communication with other devices. A registry of Device Resource Privileges shall be exchanged between the device pair during the authorization process.

6.3

Disabling Security Each IDB Device shall have a selfcontained mechanism to disable previously established certified security mechanisms. Process of authentication by Certification Authority All IDB Devices shall be assigned a unique Identifier, a Public Key and a Private Key by the Certification Authority during the devices manufacturing process. Communication of the device Public Keys and Identifiers by the Certification Authority shall occur during the authentication process, and all previously Authenticated IDB Devices shall be made aware of new devices information, and vice-versa. The unique Identifier and Public Key shall be known and recorded by all interested parties but the Private Key shall not be known or recorded by any party including the manufacturer or the Certification Authority. The Private Key shall be recorded in the secure device in such a manner that it cannot be changed or read by any external device. The purpose of the authentication process is to enable the establishment of a symmetric encryption key between the device pairs for the device pair's secure communication. The following procedure shall be executed when a new IDB Device A wants to use the resources available on an existing IDB: a. b. c. d. e. IDB Device A shall contact an approved third party Certification Authority. IDB Device A identifies itself and makes this request to the third party Certification Authority by encrypting its request using the third party Certification Authoritys known Public Key. Only the third party Certification Authority can decrypt this request by decryption using it's Private Key. The third party Certification Authority now needs to know that the request came from IDB Device A and not from a rogue device pretending to be IDB Device A. The third party Certification Authority does this confirmation by the encryption of a confirmation request first by IDB Device A's Public Key and then by encryption of the encrypted confirmation request using its Private Key.

6.4

-8-

SAE J1760 Issued DEC2001 f. g. h. i. j. Only the true IDB Device A confirmation can be correctly decrypted first with the third party Certification Authoritys Public Key and then with its own Private Key. IDB Device A returns the confirmation to the third party Certification Authority by encrypting the confirmation using the third party Certification Authoritys known Public Key. Only the third party Certification Authority can decrypt this message by using its Private Key and check that it is the confirmation it originally sent. The third party Certification Authority now has confirmation that the request from IDB Device A is legitimate and not just Masquerading as IDB Device A. The third party Certification Authority now contacts the other device(s) on the IDB with which IDB Device A is now authorized to communicate, using the same procedure previously outlined. The other device could be the IDB Gateway or any other IDB Device.

6.5

The Process to Establish an Ability to Conduct Secured Communication on the IDB Network between Device Pairs Upon completing the authentication process described in section 6.4 above, the IDB Devices shall then establish normal communication between device pairs. The following procedure shall be executed when IDB Device A desires to communicate with IDB Device B via a Symmetric Key. Note: The IDB also shall accommodate broadcast communications and not just exchanges with device pairs. a. IDB Device A contacts IDB Device B with a message identifying itself in the data. The data shall be comprised of a request for Symmetric Key. The data of this message shall be encrypted with both the Private Key of IDB Device A and the Public Key of IDB Device B. IDB Device B decrypts the message with its Private Key and the Public Key of IDB Device A. IDB Device B now knows that IDB Device A is the sender of the message. IDB Device B returns a message to IDB Device A, with the data being a Symmetric Key as set forth in this Recommended Practice. IDB Device B shall encrypt this message with both its Private Key and the Public Key of IDB Device A. IDB Device A decrypts the message with its Private Key and the Public Key of IDB Device B. IDB Device A now knows that IDB Device B is the sender of the message and IDB Device A now has the device pairs (i.e., IDB Device A / IDB Device B) Symmetric Key. IDB Device A acknowledges receipt of the Symmetric Key by sending a message to IDB Device B encrypted with the Symmetric Key. Normal secured communication may now take place between the device pair of IDB Device A and IDB Device B. IDB Device A and IDB Device B shall each exchange available resource information, including the security level that each resource must have to be accessed. Security levels are discussed in 6.1

b. c.

d.

e. f. g.

The establishment of a Symmetric Key needs to be accomplished only once for the duration of the existence of a device pair within a vehicle. However, if a Security Breach has been detected or even a Security Breach attempt detected, devices shall establish a new Symmetric Key. NOTEThe IDB also shall accommodate broadcast communications and not just exchanges with device pairs. The existence of a Symmetric Key for a device pair does not necessitate communication utilizing the Symmetric Key. However, if the existence of an non-authenticated module is detected, it shall be interpreted as a Security Breach and shall be handled as such.

PREPARED BY THE SAE ITS DATA BUS COMMITTEE

-9-

SAE J1760 Issued DEC2001 APPENDIX A PROBLEM SCENARIOS THAT REQUIRE SECURITY A.1 Background Some manufacturers of consumer products have the vision of permitting communication exchange between all vehicle electronics devices and ITS modules without the restrictions of data security, i.e., Class 0. Some OEM vehicle manufacturers have the reverse vision of only permitting data exchange between their own or designated manufacturers devices, i.e., Class 4. While both security levels are permitted (Ref 6.1) by this document there is need for a more functional approach. a. b. c. d. Class 0 security level, e.g., as defined by SAE SAE J2355 the ITS Data Bus Architecture Reference Model. Class 1 security level, e.g., prevents Masquerading or a third party attempt at pretending to send data that originates from a trusted electronic source. Class 2 security level, e.g., prevents Manipulation where a third party changes (corrupts) data transferred between trusted electronic units. Class 3 security level, e.g., prevents the use of data obtained by Eavesdropping a process where a third party passively listens to the transfer of information between trusted electronic units in an attempt to gather knowledge.

A.2

Need for Data SecurityClearly there is a need for data security for products that exchange data between the vehicle and an external device. This data security shall protect charge card or credit misuse and is essential for supporting functions such as the following: a. b. c. d. e. Fueling a vehicle Passage of a toll both Emergency Call Receiving cash from ATM type facility Parking in a parking facility

A.3

Assure Proper FunctionAnother requirement for data security shall assure proper function between ITS modules that have been designed to function together and for the purpose of eliminating improper designed equipment from malfunction and misuse. a. b. c. In order to protect the vehicle security resources the OEMs gateway module to the Vehicle Data Bus shall also be considered an ITS module. To assure proper function the ITS module that provides the resource access both to and/or from another ITS module shall define the level of security required. Eliminate malfunction of unauthorized module and associated warranty.

A.4

Disable and discourage the use of stolen ITS modulesIDB Devices shall be authenticated to function only in a designated vehicle, with the option to be authorized in multiple vehicles, (e.g., an owners vehicle and their spouses, or temporary authorization in a rental vehicle).

-10-

SAE J1760 Issued DEC2001 RationaleNot applicable. Relationship of SAE Standard to ISO Standard Not applicable. Application The scope of this SAE Recommended Practice is to require the use of the same Security Services as defined by the International Standard ISO/CD 15764, modified by the Class of Security as determined by the resource provider and referenced in Table 1, Extended Data Link Security References. Reference Section SAE J2355ITS Data Bus Architecture Reference Model ANSI X9.52American National Standard for Financial ServicesTriple Data Encryption Algorithm Modes of Operation ISO/CD 15764Road vehiclesExtended data link security ISO/IEC9797-2Information technologySecurity techniquesData integrity mechanism using a cryptographic check function emplopying a block cipher algorithm ISO/IEC10118-3Information technologySecurity techniquesHash-functionsPart 3: Dedicated hash-functions ISO/IEC11770-1Information Framework technologySecurity techniquesKey managementPart 1:

ISO/IEC11770-3Information technologySecurity techniquesKey Mechanisms using asymmetric techniques Developed by the SAE ITS Data Bus Committee

managementPart

3: