1、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 therefro
2、m, 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-0790SAE WEB ADDRESS http:
3、/www.sae.orgCopyright 2001 Society of Automotive Engineers, Inc.All rights reserved. Printed in U.S.A.SURFACEVEHICLE400 Commonwealth Drive, Warrendale, PA 15096-0001RECOMMENDEDPRACTICEJ1760ISSUEDDEC2001Issued 2001-12Data Security Services ForewordThe ISO/CD 15764 Road vehicles Extended data link sec
4、urity International Standard requiresSecurity Services for all data transfer between a vehicle and a diagnostic scan tool. In summary, this standardrequires Authentication of the scan tool and the vehicle by a Certification Authority and all communicationinterchange of data to use an encryption meth
5、od for every instance or session of use. The objective of this SAEJ1760 Recommended Practice is to require the use of these same Security Services modified by the Class ofSecurity required by the data to be exchanged as determined by the Resource Provider. This document requiresonly a one time Authe
6、ntication 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 CONTENTS1. Scope . 21.1 The IDB 31.2 IDB Device . 31.3 Classes of Security. 31.4 Theft Deterrent . 3 1.5 Compatible IDB Devices. 31
7、.6 Data Security Service Execution 42. References . 42.1 Applicable Documents 42.2 Related Publications . 43. Definitions. 43.1 Access 4 3.2 Authenticated Device . 4 3.3 Authentication . 43.4 Certification Authority . 43.5 Ciphertext . 43.6 Classes of Security. 53.7 Decryption 53.8 Device Resource P
8、rivileges 53.9 Eavesdropping . 53.10 Encryption 53.11 Hash Function 53.12 IDB Device . 5SAE J1760 Issued DEC2001-2-3.13 IDB Gateway.53.14 Manipulation .53.15 Masquerading .53.16 Passwords or PINs .53.17 Private Encryption Key .53.18 Private Key .53.19 Proxy.53.20 Public Encryption Key.53.21 Public K
9、ey .53.22 Resource Provider 53.23 Security Breach 53.24 Security Service53.25 Symmetric Key64. Abbreviations/Acronyms .65. Functional Requirements 65.1 Authentication .65.2 Access 65.3 Message Security .65.4 Security Breach Avoidance .65.5 Vehicle Device Transfer65.6 Usability 76. Security Model 76.
10、1 Security Levels of IDB Device Resources 76.2 Enabling Security86.3 Disabling Security .86.4 Process of authentication by Certification Authority .86.5 The Process to Establish an Ability to Conduct Secured Communication onthe IDB Network between Device Pairs9Appendix A Problem Scenarios that Requi
11、re Security. 10A.1 Background . 10A.2 Need for Data Security . 10A.3 Assure Proper Function 10A.4 Disable and discourage the use of stolen ITS modules 101. ScopeThe scope of this SAE Recommended Practice is to require the use of the same Security Services asdefined by the International Standard ISO/
12、CD 15764, modified by the Class of Security as determined by theresource provider and referenced in Table 1, Extended Data Link Security References.TABLE 1EXTENDED DATA LINK SECURITY INTERNATIONALSTANDARD ISO/CD 15764 REFERENCESParameter References ValuesHashing Function ISO/IEC 9797-2ISO/IEC 10118-
13、3Symmetric Key ANSI X 9.52 128 bitsPublic Key ISO/IEC 11770-1ISO/IEC 11770-31024 bits modulus1024 bits exponentPrivate Key ISO/IEC 11770-1 1024 bits modulus1024 bits exponentSAE J1760 Issued DEC2001-3-1.1 The IDB GatewayThe IDB Gateway shall be considered an IDB Device operating on the IDB network.
14、ThisSAE 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 betweenthe IDB Gateway and the vehicle are not within the scope of this document.1.2 IDB Device Functions
15、The device functions may be represented by “proxy”. Therefore devices such asthose 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 bythis document
16、. The Security Services required between the IDB network and outside the bounded vehiclecommunication system shall be within the scope of this document. (Reference Figure 1 for a data securityservices system diagram.)1.3 Classes of SecurityVarious capabilities (messages) shall be protected by differ
17、ent classes of security asrequired 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 IDBDevices FIGUR
18、E 1DATA SECURITY SERVICE SYSTEM DIAGRAM1.5 Compatible IDB DevicesAll IDB Devices operating on the IDB network that claim to be IDB compatible andutilize resources from an IDB compatible device shall comply with the requirements set forth in thisRecommended Practice.SAE J1760 Issued DEC2001-4-1.6 Dat
19、a Security Service ExecutionThis Recommended Practice defines the functional requirements forproviding data security service execution with IDB Devices. The methods used in implementing these servicesare found in the ISO/CD 15764 Road vehicles Extended data link security International Standard.2. Re
20、ferences2.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-0001SAE
21、J2355ITS Data Bus Architecture Reference Model2.1.2 ANSI PUBLICATIONAvailable from ANSI, 25 West 43rd Street, New York, NY 10036-8002ANSI X9.52American National Standard for Financial ServicesTriple Data Encryption AlgorithmModes of Operation2.1.3 ISO P UBLICATIONSAvailable from ANSI, 25 West 43rd S
22、treet, New York, NY 10036-8002.ISO/CD 15764Road vehiclesExtended data link securityISO/IEC9797-2Information technologySecurity techniquesData integrity mechanism using acryptographic check function emplopying a block cipher algorithmISO/IEC10118-3Information technologySecurity techniquesHash-functio
23、nsPart 3: Dedicatedhash-functionsISO/IEC 11770-1Information technologySecurity techniquesKey managementPart 1: FrameworkISO/IEC11770-3Information technologySecurity techniquesKey managementPart 3:Mechanisms using asymmetric techniques2.2 Related PublicationsThe following publications are provided fo
24、r information purposes only and are not arequired part of this document.2.2.1 SAE PUBLICATIONSAvailable from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001.SAE J2366 and all its partsSAE J2367IDB GatewaySAE J2590PMODE for In-Vehicle Networks3. Definitions3.1 AccessThe process of retrieving d
25、ata from or sending to another authenticated device, such that the dataand/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 secureservices through a process of authentication.3.3 Authentic
26、ationThe process of confirming, through the utilization of a Certification Authority, that an IDBDevice satisfies the requirements defined in this Recommended Practice.3.4 Certification AuthorityThe Certification Authority is an organization that issues Public Key certificateswhich contain the name
27、of a person (device manufacturer), the persons Public Key (devices Public Key),serial number, start and end date, and other information.3.5 CiphertextA disguised or encrypted file or message.SAE J1760 Issued DEC2001-5-3.6 Classes of SecuritySecurity classes are defined in Section 6.1 as levels of tr
28、ust 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 anotherIDB Device B or cause execution of an actuator controlled by IDB Device
29、 B on command. 3.9 EavesdroppingA means by which a third party passively listens to the transfer of information betweentrusted 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 mechani
30、sm for detecting alteration of a message or file enroute from the distributor to therecipient(s). 3.12 IDB DeviceAny ITS Data Bus (IDB) node per 6.1 or module that requires Security Services from anotherIDB Node or module as defined in this document. Note the IDB is not limited to copper wire physic
31、al layerinterfaces.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 trustedelectronic units.3.15 MasqueradingA process by which a third party sends data p
32、retending that it originates from the trustedelectronic unit.3.16 Passwords or PINsA group of characters used to access protected information, such as personal e-mail. Apassword or a PIN usually consists of three to ten alphanumeric characters.3.17 Private Encryption KeyA key used for private encryp
33、tion. (See Private Key)3.18 Private KeyThe secret key of a public-private key cryptography system. This key is used to “sign” outgoingmessages, and is used to decrypt incoming messages. (See Private Encryption Key)3.19 ProxyA substitute device such as an intermediate server or other electronic devic
34、e.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 Keycan decrypt
35、the file or message. (See Public Encryption Key)3.22 Resource ProviderThe manufacturer or the representative of a IDB Device that provides Security Servicesto 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
36、 transfer information betweenthemselves 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 ofinformation between two trusted electronic units. Breach atta
37、cks shall include Eavesdropping, Manipulation,and Masquerading. The services shall also discourage the theft of the IDB Device.SAE J1760 Issued DEC2001-6-3.25 Symmetric KeyThe key that is used to encrypt a file or message is the same key that is used to decrypt thefile or message after an authentica
38、tion process has taken place between the two devices.4. Abbreviations/AcronymsIDB ITS Data BusITS Intelligent Transportation System5. Functional Requirements5.1 AuthenticationA device attached to the IDB shall have a security mechanism to authenticate anotherdevice attached to the IDB. The Authentic
39、ated Device will then be allowed to request resources (this could bea 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 AuthenticatedDevice is capable of u
40、sing upon Authentication of that device.a. Authenticating Devices shall have the ability to accomplish (grant) multiple classes of security accessto various devices requesting resources that the Authenticating Device controls (even through proxy).b. A registry of access enabled Device Resource Privi
41、leges for each security class shall be used todescribe the various capabilities of each security class. Classes may range from full access ofresources to no access.5.3 Message SecurityThe request mechanism to utilize another devices resources shall have the ability tohave security features built int
42、o 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 ofan active, prior authenticated, IDB Device. The security mechanism within a device shall not be able to beobtained through a
43、physical break-in to or interrogation of that device. The security mechanism within a deviceshall not be able to be altered. One successful breach will not be able to be applied to subsequent breacheswithin the same system or other like systems.Upon three successive, unsuccessful Authentication atte
44、mpts in a Certification Authority session by a device, ainfinite period of “no retry” shall be imposed for that device. This shall not preclude the use or functionality ofproperty functioning and authenticated devices on the IDB.The most secure Authentication requirement method shall provide a proba
45、bility of, at most, one SecurityBreach 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
46、compatibledevice in more than one vehicle, assuming that the device requires and/or delivers secured resources:5.5.1 AUTHORIZATION FOR VEHICLE TO VEHICLE T RANSFERThe device security mechanism shall have the ability torestrict unwanted vehicle to vehicle transfer (IDB to IDB). All devices on the IDB
47、 shall be authenticated bythe Certification Authority. Any transfer of devices from one vehicle to another must also undertake theauthentication process. If a device is not authenticated to the other IDB Devices in the vehicle, increasedsecurity shall occur such that a non-authenticated IDB Device s
48、hall be unable to access the securedresources 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 a
49、uthorization will last, andauthorization shall expire when the time period elapses.SAE J1760 Issued DEC2001-7-b. Authorization shall also be required when a device is to operate in more than one vehicle. This case ofmultiple authorization shall require all devices and vehicles slated for this multiple authorization to bepresented 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 s
