SAE-2020-J3101 “ Hardware Protected Security for Ground Vehicle” is a standard released by the American Automotive Association in 2016 regarding vehicle hardware security, which stipulates the hardware protection security requirements for ground vehicle applications.The hardware here specifically refers to hardware such as HSM.
SAE J3101 specifies the requirements for these hardware components. SAE J3101 is classified as a best practice document, focusing on the network security technology requirements related to hardware within the entire cybersecurity framework.
The following translation is for industry learning reference only. Please forgive any inaccuracies.
Automotive computer systems need to establish trust through device identification, sealing, proof, data integrity, and availability. These systems must be able to withstand a wide range of attacks that cannot be prevented by purely software-based security mechanisms. Trusted hardware roots and hardware-based security primitives are fundamentally necessary to meet the demands of connected and highly automated or fully automated vehicles. This document provides a comprehensive view of the security mechanisms supported by hardware for automotive use cases, as well as best practices for using such mechanisms. The goal of this document is to provide a universal reference to facilitate communication among engineers in different parts of the automotive supply chain regarding hardware security features. Silicon vendors will find this document helpful in understanding the fundamentals of hardware security and its corresponding use cases and applications to meet vehicle safety requirements. This document should also bring more order to the diversity of hardware security features, thus considering the final use case when developing products and having appropriate security levels. ECU suppliers and system integrators will benefit from the different security requirements and use cases outlined here when assessing threats that impact their systems and the right hardware systems needed to address those threats.
This document introduces the characteristics of hardware mechanisms that meet the automotive industry’s requirements, to gain deeper insights into the silicon industry and prevent fragmentation.
The automotive industry needs a document to provide a benchmark for product development due diligence. This document aims to meet this need as a reference for the industry best practices regarding the minimum expectations for hardware-protected cybersecurity.
This document proposes a set of common requirements to be achieved in hardware-assisted functions to facilitate the ideal system for hardware protection of ground vehicle applications.
This document will outline a set of common requirements to meet this goal and provide examples of using such requirements in various use cases throughout the product lifecycle of ground vehicles without explicitly detailing implementation requirements.
SAE J3101 adopts an approach to define requirements through basic use cases. These requirements become the cornerstone of innovation but are not aimed at the development process. The proposed building blocks do not attempt to cover all potential future innovations; however, through creatively combining the proposed requirements, a significant amount of future innovation should be possible. It should be expected that some innovations may generate future core requirements, which will themselves become new building blocks not covered within the scope of this document’s revisions.
This standard is written from the perspective of automotive manufacturers and suppliers, targeting embedded component suppliers such as microcontroller vendors. Although consumer automotive applications dominate the illustrated use cases, this document is intended to apply to any ground vehicle application. The governmental applications suggested in this document are “non-tactical,” characterized by the repurposing of civilian vehicles for government purposes. This document specifically does not include use cases for military applications.
The following publications constitute a part of this specification within the scope defined herein. Unless otherwise specified, the latest version of SAE publications shall apply.
Available from SAE International, website: www.SAE.org.
SAE J3061 Cyber-Physical Vehicle Systems Cybersecurity Guidelines
Copies of these documents are available online at http://webstore.ansi.org/.
ISO/IEC 2382:2015 Information Technology – Vocabulary
ISO/IEC/IEEE DIS 8802-1 AE Information Technology – Telecommunications and Information Exchange between Systems – Local Area Networks and Metropolitan Area Networks – Part 1AE: Media Access Control (MAC) Security
ISO/IEC 9797-1:2011 Information Technology – Security Techniques – Message Authentication Codes (MAC) – Part 1: Mechanisms Using Block Ciphers
ISO/IEC 9797-2:2011 Information Technology – Security Techniques – Message Authentication Codes (MAC) – Part 2: Mechanisms Using Dedicated Hash Functions
ISO/IEC 10116:2017 Information Technology – Security Techniques – Modes of Operation for N-Bit Block Ciphers 15782-1:2009
ISO/IEC 17025:2017 General Requirements for the Competence of Testing and Calibration Laboratories
ISO 18031:2011 Information Technology – Security Techniques – Random Number Generation
ISO/IEC 18033-3:2010 Information Technology – Security Techniques – Encryption Algorithms – Part 3: Block Ciphers ISO 19772
ISO/IEC 19790:2012 Information Technology – Security Techniques – Security Requirements for Cryptographic Modules/SAE DIS 21434
ISO 26262-1:2011 Road Vehicles – Functional Safety – Part 1: Vocabulary
ISO/IEC 27000:2016 Information Technology – Security Techniques – Information Security Management Systems – Overview and Vocabulary
ISO 29192-2:2012 Information Technology – Security Techniques – Lightweight Cryptography – Part 2: Block Ciphers
Available from NIST, address: 1070 Station 100 Bureau Drive, Gaithersburg, MD 20899-1070, phone: 301-975-6478, www.NIST.gov.
NIST SP 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques (December 2001)
NIST SP 800-38B Recommendation for Block Cipher Modes of Operation: CMAC Authentication Mode (May 2005)
NIST SP 800-38C Recommendation for Block Cipher Modes of Operation: CCM Authentication and Confidentiality Mode (July 2007)
NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (November 2007)
NIST SP 800-38E Recommendation for Block Cipher Modes of Operation: XTS-AES Mode for Confidentiality of Storage Devices (January 2010)
NIST SP 800-38F Recommendation for Block Cipher Modes of Operation: Key Wrapping Methods (December 2012)
NIST SP 800-47 Security Guide for Interconnecting Information Technology Systems (August 2002)
NIST 800-53A Assessing Security and Privacy Controls for Federal Information Systems and Organizations: Developing Effective Assessment Plans (December 2014)
NIST SP 800-57 Part 1, Revision 4: Recommendations for Key Management, Part 1: General (January 2016)
SP 800-90A Recommendation for Random Number Generation Using Deterministic Random Bit Generators (June 2015)
SP 800-90B Recommendation for Entropy Sources Used for Random Bit Generation (January 2018)
SP 800-90C [Draft] Recommendation for Random Bit Generator (RBG) Structure (April 2016)
NIST SP 800-131A Revision 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019)
NIST IR 7316 Access Control System Assessment (September 2006)
FIPS PUB 140-2 Security Requirements for Cryptographic Modules (May 2001)
FIPS PUB 140-3 Security Requirements for Cryptographic Modules (March 2019)
FIPS PUB 186-4 Digital Signature Standard (DSS) (July 2013)
FIPS PUB 180-4 Secure Hash Standard (SHS) (August 2015)
FIPS PUB 197 Advanced Encryption Standard (AES) (November 2001)
FIPS PUB 198-1 Keyed-Hash Message Authentication Code (HMAC) (July 2008)
FIPS PUB 199 Standards for Security Categorization of Federal Information and Information Systems (February 2004)
FIPS PUB 202 SHA-3 Standard: Permutation-Based Hash and Extendable Output Functions (August 2015)
Cryptographic Algorithm Validation Program (CAVP) https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program
Cryptographic Module Validation Program (CMVP) https://csrc.nist.gov/projects/cryptographic-module-validation-program
Interoperable Randomness Beacon https://csrc.nist.gov/projects/interoperable-randomness-beacons
Entropy as a Service https://csrc.nist.gov/projects/entropy-as-a-service
NISTCAVP – Cryptographic Algorithm Validation Program https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation
NISTDRBG – Cryptographic Algorithm Validation Program (DRBG) https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation/validation-list/drbg
NISTRNG – Cryptographic Algorithm Validation Program (RNG) https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation/validation-list/rng
2.1.3.1 IETF Publications
Copies of these documents are available online at http://tools.ietf.org/
RFC 7696 Guidelines for Cryptographic Algorithm Agility and Selection of Mandatory-to-Implement Algorithms
RFC 4949 Internet Security Glossary, Version 2 (August 2007)
RFC 6979 Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (August 2013)
RFC 8391 XMSS: Extended Merkle Signature Scheme (May 2018)
RFC 7905 ChaCha20-Poly1305 Transport Layer Security (TLS) Cipher Suite (June 2016)
IETF Protocol RFC 8439 ChaCha20 and Poly1305 (June 2018)
RFC 7748 Elliptic Curve Security (January 2016)
RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA) (January 2017)
RFC 8554 Leighton-Micali Hash-Based Signatures (April 2019)
RFC 8125 PAKE Scheme Requirements (April 2017)
2.1.3.2 IEEE Publications
Available from the IEEE Operations Center, address: 445 and 501 Hoes Lane, Piscataway, NJ 08854-4141, phone: 732-981-0060, www.IEEE.org.
IEEE 1609.2-2016 Security Services for Wireless Access in Vehicular Environments
IEEE 1619-2018 Encryption Protection of Data on Block Storage Devices
ANSI X9.62, “Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA),” 2005.
IEEE-ISTO 6100.1.0.0, “Uptane Design and Implementation Standard,” 2019.
ITU-T X.509, “Information Technology – Open Systems Interconnection – Directory: Public Key and Attribute Certificate Framework,” International Telecommunication Union, October 2016, https://www.itu.int/rec/T-REC-X.509.
BSI AIS 20/31, “Evaluation of Random Number Generators,” Bundesamt für Sicherheit in der Informationstechnik, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Interpretationen/AIS_20_AIS_31_Evaluation_of_random_number_generators_e.pdf.
Menezes, A.J., van Oorschot, P.C., and Vanstone, S.A., “Algorithm 9.43,” Handbook of Applied Cryptography, August 2001, CRC Press, ISBN 0-8493-8523-7, http://cacr.uwaterloo.ca/hac/.
United States Code Title 44 Section 3542: United States Code Title 44 Section 3542 – “Definitions”
Blake Wilson, S., Menezes, A., “Unknown Key Share Attack on Station-to-Station (STS) Protocol,” Computer Science Lecture Notes, 1560, Springer, 154-170 1999.
Dan Kaminsky “Black Hat” Blog, https://dankaminsky.com/2012/08/06/bo2012/ – Black Hat 2012.
[Shor’s Algorithm] Peter W. Shor. 1997. “Polynomial Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J.Comput. 26, 5, 1484-1509 1997, doi:http://dx.doi.org/10.1137/S0097539795293172.
[PQC_NIST] Dustin Moody, This Ship Has Sailed: NIST Post-Quantum Cryptography “Competition,” NIST.
TCG TPM 2.0 Library r1.38 (February 2017), https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.38.pdf.
Weimerskirch and Schramm, “Using Software Flashing to Secure Embedded Device Updates,” http://www.embedded.com/design/configurable-systems/4008264/3/Using-software-flashing-to-secure-embedded-device-updates.
3. Definitions
The following are further refinements of the terms defined in SAE J3101.
Access Control: The use of resources (ISO/IEC 2382:2015). Access control involves determining the allowed activities of legitimate users, determining the permissions for users to access system resources each time, thereby protecting system resources from inappropriate or unwanted user access (NIST: Access Control System Assessment).
Asset: Anything of value to the stakeholders of the product. Assets can be tangible or intangible. Examples of tangible assets include ECUs, sensors, or actuators. Examples of intangible assets include reputation or intellectual property (ISO 21434 (Draft)).
Authentication: A specification that guarantees the correctness of the characteristics claimed by an entity (ISO 27000-2016).
Authorization: Granting permissions (ISO 15782-1-2009).
Critical Security Parameter (CSP): Information related to security (e.g., counters, authentication data such as passwords and Personal Identification Numbers (PINs)) whose disclosure or modification may compromise the security of cryptographic operations (FIPS 140-2).
CRYPTO Agility: The ability to transition from one implemented algorithm suite to another over time (RFC 7696).
Cybersecurity Properties:
a. Availability: Ensures timely and reliable access to and use of information (data) (United States Code Title 44 Section 3542). The property of being accessible and usable upon request by authorized entities (ISO/IEC 27000-2016). Loss of availability is an interruption of access to or use of information or information systems (FIPS 199).
b. Confidentiality: Preserving authorized restrictions on access and disclosure of information, including means for protecting personal privacy and proprietary information (United States Code Title 44 Section 3542). The property of information that is not made available or disclosed to unauthorized individuals, entities, or processes (ISO/IEC 27000:2016).
c. Integrity: Preventing improper information modification or destruction, including ensuring the non-repudiation and authenticity of information (United States Code Title 44 Section 3542). Accuracy and completeness (ISO/IEC 27000-2016).
Firmware: A computer program and data stored in hardware; such that the program and data are generally not dynamically written or modified during the execution of the firmware (RFC 4949). Firmware can be updated by authorized controlled mechanisms.
Freshness: Data is current (up-to-date), ensuring that it is not replaced by old (previously used) data.
Identification: The process of verifying the identity of a user, process, or device, typically as a prerequisite for granting access to information technology system resources (NIST SP 800-47).
KEYSTORE: A keystore is a facility for storing keys for cryptographic applications providing security services (see 6.2).
Resource/Object: An entity in the system that contains or receives information or can perform actions or functions. Access to a resource means access to the information and/or functionality of that resource.
Security Mechanism: System elements that include specific protective functions to provide cybersecurity (NIST 800-53A).
Self-Test: A test program executed automatically and/or on demand by a hardware-protected secure environment to ensure the module operates correctly (FIPS 140-2).
Zeroization: A method for erasing electronic storage data, cryptographic keys, and critical security parameters by changing or deleting the contents of data storage to prevent data recovery (FIPS 140-2).
