saej1760v001

8/13/2019 saej1760v001

1/11

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 entirelyvoluntary, 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

SURFACEVEHICLE

400 Commonwealth Drive, Warrendale, PA 15096-0001RECOMMENDEDPRACTICE

J1760ISSUED

DEC2001

Issued 2001-12

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 backgrounddiscussion on the problem scenarios that require security, see Appendix A.

TABLE OF CONTENTS

1. Scope....................................................................................................................................................... 2

1.1 The IDB .................................................................................................................................................... 3

1.2 IDB Device ............................................................................................................................................... 3

1.3 Classes of Security................................................................................................................................... 3

1.4 Theft Deterrent ......................................................................................................................................... 3

1.5 Compatible IDB Devices........................................................................................................................... 3

1.6 Data Security Service Execution .............................................................................................................. 4

2. References............................................................................................................................................... 42.1 Applicable Documents..............................................................................................................................4

2.2 Related Publications ................................................................................................................................. 4

3. Definitions................................................................................................................................................. 4

3.1 Access ...................................................................................................................................................... 4

3.2 Authenticated Device ............................................................................................................................... 4

3.3 Authentication........................................................................................................................................... 4

3.4 Certification Authority ............................................................................................................................... 4

3.5 Ciphertext ................................................................................................................................................. 4

3.6 Classes of Security................................................................................................................................... 5

3.7 Decryption ................................................................................................................................................ 5

3.8 Device Resource Privileges...................................................................................................................... 5

3.9 Eavesdropping ......................................................................................................................................... 53.10 Encryption ................................................................................................................................................ 5

3.11 Hash Function .......................................................................................................................................... 5

3.12 IDB Device ............................................................................................................................................... 5

8/13/2019 saej1760v001

2/11

SAE J1760 Issued DEC2001

-2-

3.13 IDB Gateway.............................................................................................................................................5

3.14 Manipulation .............................................................................................................................................5

3.15 Masquerading...........................................................................................................................................5

3.16 Passwords or PINs ...................................................................................................................................5

3.17 Private Encryption Key .............................................................................................................................5

3.18 Private Key ...............................................................................................................................................5

3.19 Proxy.........................................................................................................................................................53.20 Public Encryption Key...............................................................................................................................5

3.21 Public Key.................................................................................................................................................5

3.22 Resource Provider ....................................................................................................................................5

3.23 Security Breach ........................................................................................................................................5

3.24 Security Service........................................................................................................................................5

3.25 Symmetric Key..........................................................................................................................................6

4. Abbreviations/Acronyms ...........................................................................................................................6

5. Functional Requirements ..........................................................................................................................6

5.1 Authentication ...........................................................................................................................................6

5.2 Access ......................................................................................................................................................65.3 Message Security .....................................................................................................................................6

5.4 Security Breach Avoidance .......................................................................................................................6

5.5 Vehicle Device Transfer............................................................................................................................6

5.6 Usability ....................................................................................................................................................7

6. Security Model..........................................................................................................................................7

6.1 Security Levels of IDB Device Resources ................................................................................................7

6.2 Enabling Security......................................................................................................................................8

6.3 Disabling Security .....................................................................................................................................8

6.4 Process of authentication by Certification Authority .................................................................................8

6.5 The Process to Establish an Abil ity 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. Scope 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.

TABLE 1EXTENDED DATA LINK SECURITY INTERNATIONAL

STANDARD ISO/CD 15764 REFERENCES

Parameter References Values

Hashing Function ISO/IEC 9797-2

ISO/IEC 10118-3

Symmetric Key ANSI X 9.52 128 bits

Public Key ISO/IEC 11770-1

ISO/IEC 11770-3

1024 bits modulus

1024 bits exponent

Private Key ISO/IEC 11770-1 1024 bits modulus

1024 bits exponent

8/13/2019 saej1760v001

3/11


-3-

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.

1.2 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 vehiclecommunication 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.)

1.3 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.

1.4 Theft DeterrentThe data security services shall provide a mechanism that will discourage the theft of IDB

Devices

FIGURE 1DATA SECURITY SERVICE SYSTEM DIAGRAM

1.5 Compatible IDB DevicesAll 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.

8/13/2019 saej1760v001

4/11


-4-

1.6 Data Security Service ExecutionThis 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.

2. References

2.1 Applicable PublicationsThe following publications form a part of this specification to the extent specifiedherein. Unless otherwise indicated, the latest version of SAE publications shall apply.

2.1.1 SAE PUBLICATIONAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001

SAE J2355ITS Data Bus Architecture Reference Model

2.1.2 ANSI PUBLICATIONAvailable 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 PUBLICATIONS

Available 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.

2.2.1 SAE PUBLICATIONSAvailable 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. Definitions

3.1 AccessThe 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.

3.2 Authenticated DeviceAn IDB Device that has the attribute of confirmed authorization to access secure

services through a process of authentication.

3.3 AuthenticationThe process of confirming, through the utilization of a Certification Authority, that an IDB

Device satisfies the requirements defined in this Recommended Practice.

3.4 Certification AuthorityThe 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.

3.5 CiphertextA disguised or encrypted file or message.

8/13/2019 saej1760v001

5/11


-5-

3.6 Classes of SecuritySecurity classes are defined in Section 6.1 as levels of trust and authentication.

3.7 DecryptionAny process to convert ciphertext back to plaintext using a cryptographic algorithm.

3.8 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.

3.9 EavesdroppingA means by which a third party passively listens to the transfer of information between

trusted electronic units in an attempt to gather knowledge.

3.10 EncryptionA process to convert plaintext into ciphertext using a cryptographic algorithm.

3.11 Hash FunctionA mechanism for detecting alteration of a message or file enroute from the distributor to the

recipient(s).

3.12 IDB DeviceAny 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 GatewayAn interface between the IDB and the facilities provided by the vehicle manufacturer.

3.14 ManipulationA process by which a third party changes (corrupts) data transferred between trusted

electronic units.

3.15 MasqueradingA process by which a third party sends data pretending that it originates from the trusted

electronic unit.

3.16 Passwords or PINsA 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 KeyThe 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 KeyA 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 ProviderThe 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 BreachA 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 ServiceA 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.

8/13/2019 saej1760v001

6/11


-6-

3.25 Symmetric KeyThe 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. Functional Requirements

5.1 AuthenticationA 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.

5.2 AccessAuthenticated Devices shall be capable of communicating the resources that an Authenticated

Device is capable of using upon Authentication of that device.

a. 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).b. 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.3 Message SecurityThe 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).

5.4 Security Breach AvoidanceDevices 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.5 Vehicle Device TransferThe 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:

5.5.1 AUTHORIZATION FORVEHICLETOVEHICLETRANSFERThe device security mechanism shall have the abili ty to

restrict unwanted vehicle to vehicle transfer (IDB to IDB). All devices on the IDB shall be authenticated bythe 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.

8/13/2019 saej1760v001

7/11


-7-

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 UsabilityData 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.

6. Security Model The following principles shall apply:

a. A Certification Authority shall enable secure device to device communications.

b. Expiration of the authorization shall increase security.

c. Authorization cancellation shall be available without involvement of the Certification Authority.

d. The authentication process shall be encrypted.

e. The certification algorithms shall be standard.

f. 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.

The following principles may be deployed but are not required:

a. In addition to security mechanisms, device pairs may use passwords, or PINs.

b. 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 ResourcesClasses 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.

6.1.1 The following are definitions of the current levels of security for IDB Device resources:

a. Class 0 No defined security measures are required for requesting access to a Class 0 resource.

b. 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.

c. 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 HashFunction. 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.

8/13/2019 saej1760v001

8/11


-8-

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.

e. 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.

6.2 Enabling SecurityEach 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 theCertification 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 SecurityEach IDB Device shall have a selfcontained mechanism to disable previously

established certified security mechanisms.

6.4 Process of authentication by Certification AuthorityAll 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. IDB Device A shall contact an approved third party Certification Authority.

b. 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.

c. Only the third party Certification Authority can decrypt this request by decryption using it's Private Key.

d. 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.

e. 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.

8/13/2019 saej1760v001

9/11


-9-

f. 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.

g. 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.

h. 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.

i. The third party Certification Authority now has confirmation that the request from IDB Device A islegitimate and not just Masquerading as IDB Device A.

j. 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 PairsUpon 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 becomprised 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.

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.

c. 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.

d. 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.

e. IDB Device A acknowledges receipt of the Symmetric Key by sending a message to IDB Device B

encrypted with the Symmetric Key.

f. Normal secured communication may now take place between the device pair of IDB Device A and IDBDevice B.

g. 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

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 interpretedas a Security Breach and shall be handled as such.

PREPARED BY THE SAE ITS DATA BUS COMMITTEE

8/13/2019 saej1760v001

10/11


-10-

APPENDIX A

PROBLEM SCENARIOS THAT REQUIRE SECURITY

A.1 BackgroundSome 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 exchangebetween 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. Class 0 security level, e.g., as defined by SAE SAE J2355 the ITS Data Bus Architecture Reference

Model.

b. 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.

c. Class 2 security level, e.g., prevents Manipulation where a third party changes (corrupts) data

transferred between trusted electronic units.

d. 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. Fueling a vehicle

b. Passage of a toll both

c. Emergency Call

d. Receiving cash from ATM type facility

e. 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 designedequipment from malfunction and misuse.

a. In order to protect the vehicle security resources the OEMs gateway module to the Vehicle Data Bus

shall also be considered an ITS module.

b. 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.

c. 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).

8/13/2019 saej1760v001

11/11


RationaleNot applicable.

Relationship of SAE Standard to ISO StandardNot 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


Framework


Mechanisms using asymmetric techniques

Developed by the SAE ITS Data Bus Committee

saej1760v001

Documents

Transcript of saej1760v001