SAE-2020-J3101-硬件安全标准.pdf

发布时间：2022-06-06 发布人：admin 分类：说明书资料大小：1.78M 资料格式：pdf 举报版权申诉

challye-12462174-16359647513551169589.pdf-第1页.png

第1页 / 共80页

challye-12462174-16359647513551169589.pdf-第2页.png

第2页 / 共80页

challye-12462174-16359647513551169589.pdf-第3页.png

第3页 / 共80页

challye-12462174-16359647513551169589.pdf-第4页.png

第4页 / 共80页

challye-12462174-16359647513551169589.pdf-第5页.png

第5页 / 共80页

challye-12462174-16359647513551169589.pdf-第6页.png

第6页 / 共80页

challye-12462174-16359647513551169589.pdf-第7页.png

第7页 / 共80页

challye-12462174-16359647513551169589.pdf-第8页.png

第8页 / 共80页

文本预览

INTERNATIONAL 渝 SURFACE VEHICLE RECOMMENDED PRACTICE Issued J3101™ 2020-02 FEB2020 Hardware Protected Security for Ground Vehicles RATIONALE Automotive computer systems are requ ired to establish trustworthiness through device identity, sea ling, attestation , data integrity, and availab 山ty . These systems must be resilient to a wide range of attacks that cannot be thwarted through software-only security mechanisms. A hardware root of trust and the hardware-based security primitives are fundamentally necessary to satisfy demands of connected and highly or fully automated vehicles. This document provides a comprehensive view of security mechanisms supported in hardware for automotive use cases, along with best practices for using such mechanisms. 1. 1.1 1 :2 INTRODUCTION ........ .. ... ... ................... .............. .. ............ ............... .............. ... ................ ... ......... ........... .. 4 Scope and Objective ............................................................................................................... .. ................. 4 A~die-n~~~--~~'.~~:·.:.~.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 TABLE OF CONTENTS 2. 2.1 ; : ~.1 2.1 .2 ;:~:~ 2.1.4 REFERENCES. ... ...... ... ............ ................. .. .... .......... ................... .......... ................... ...... ..... ......... ..... .... .... 5 Applicable Documents ~~i~~~~c~~~~:.~-~~~.: :: :: :: :: : ::: : :: ::: : :: :: : : :: : : :: :::: :: : : :: :: :: :: ::: ::: : :::: :: :: :: : : :: ::: ::: : :: ::: :: : :: : : :: :: : : :: :: :: :: : : : :: : :: : :::: :: :: :: : : :: :: ; ~~;~~~~~~~~~~:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::~ Other Publications ...... .................... ....... ...... .... ............ ...... .. ... .. ...... .... .... ........ ..... .... ................ ........... .... .... 8 ISO Publications 3. 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 DEFINITIONS .. ... ...... ... .. ...... .......... ...... .. .............................. ........ ...... ............ ... .. .............. ... ......... ... .. ...... .. 8 HARDWARE PROTECTED SECURITY ENVIRONMENT ...... ..... ... ...... .… ... .. ...... ........... . .. . .. . ........... ........ 9 Defined ...... .. .. ... ... ......... .... .... ............... ... ...... ... .. .. .... .. .. ...... ... ........ ...... .. .... ....... .. .... .... .. .. .... ...... ..... ..... ... .. .. .. 9 Design with a Hardware Protected Security Environment.. .................................. .. ........ .... ..................... 10 Hardware Protected Security Abstraction Layers .............. .. .... ...... .. ......... .. ........ ......... ........ .. .. .. .. .. ........ .. 10 Safety Determination of a System Secured by a Hardware Protected Security Environment ... ........ … .11 LIFECYCLE OF HARDWARE PROTECTED SECURITY IN A VEHICLE .…· ….. .. … …………………………. 11 Engineering Development. ..................................................... ................................................ .................. 11 Component Integration..... ......... .. ... ... ... ..... .. ............. ..... ......... .. .... .......... ... .. .... .... .... .. .. ...... .. ... ... ......... .. .... 11 Manufacture/Production ....... ..... ........ .. ..... ... ........ ........ ............ ..... .. .. ... ............ ... ....... .. ........ .... ... .............. 12 Distribution c~~i;;-~;;·u~~· :: :::::: :::: :: :: : : :: :: : ::: : : : ::: :: : :: :::: :: : : :: :: :: : : :: :: : : ::: : : ::: : : : :: :: :: :: : : :: :: : : :: ::: ::: :: ::: : : :: :: : : :: :::: :: :: : :: : :: : :: :: :: :: :: : : :: 12 12 R~;~i~1R;~~~diti~~1~~-: :: : : : : : :: ::: : :: : :: : :: :: : : :::::: :::: :: : : :: : ::: : : ::: ::: : :: :: : : :::::: :: : :: ::: : :: ::: :: : :: : : :: :: :: :: ::: ::: :: : Aftermarket Alteration 12 Resale/Reconditionina ..... ..... .... ...... .... .. .... .. .... .. ... ............. ... .... .... .. .. ...... ......... .. .. ...... .. ...... ..... .... .. .. .. .. .. .. .. 12 Disposal/Retirement ...................................................... ........................................................................... 12 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 revised, reaffirmed, stabilized, or cancelled. SAE invites you r written comments and suggestions. Copyright © 2020 SAE International All 廿gh ts reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise. without the prior written permission of SAE TO PLACE A DOCUMENT ORDER: SAE values your input. To provide feedback on this Technical Report, please visit h t t~2002 SAE WEB ADDRESS: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-4970 (outside USA) Fax: 724-776-0790 Email: CustomerService@sae.org http://www.sae.org

SAE INTERNATIONAL J3101 TM FEB2020 Page 2 of 80 6. 6.1 6.2 6.2.1 6.2.2 6.2.3 2云4 6.3.1 6.3.2 6.3.3 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.5 6.5.1 6.5.2 6.5.3 6.6 6.6.1 6.6.2 6.7 6.7.1 6.7.2 6.8 6.8.1 6.8.2 6.8.3 6.9 6.9.1 6.9.2 6.9.3 COMMON REQUIREMENTS ......................... .... ..... .... .......... .................................................................. 12 Mandatory versus Optional and Required versus Conditional Presentation of Requirements … ………… . 13 Cryptographic Key Protection ......................... ......................................................................................... 13 Cryptographic Key Management Primer... .. ..... .............. .. ................................. .. ................. .... .... .. .......... 13 Cryptographic Key Protection Overview .................................................................................................. 14 Requirements ... ... ....... .............. ......... .................. ........ ........... .......... ........ ... ................ ........ .... ... .............. 15 61~心芯ra$岱:SA心＄：盄器:Jae心d ProtocoIs 努 Cryptographic Algorithms Overview................ ................................. ... ............... ..... ............... .................. 27 Requirements ............. .... .. ........ ........ ........ .. ... .... ..................... ............. .......... .... ............... ... ... ....... ... .... .... 28 Implementation Considerations (Informative) ................. ........ .......... .. ........ .. ............................... .... ........ 30 Random Number Generation .............. .. .... .... .. .... ... ........ .... .. ....... ..... ... ... .. ... .. .. .... .... ................... .. .... .. .. .. .. 30 Random Number Generation Overview ................................................................................................... 30 Requirements ... ... ................... .......... ................................... ... .... ........ ......................... ............ ... .............. 30 Implementation Considerations (Informative) ....................................................... ................................... 31 Understanding and Managing Entropy .................................................................................................... 32 Nonvolatile Critical Security Parameters. .. ............ ......... .................. ... ........ .. .. .... ....................... .. .... ...... .. 32 Nonvolatile Critical Security Parameters Overview ................................................................. ................ 32 Requirements: Required ............................................................................................. ............................. 32 Implementation Considerations (Informative) .......................... ........ ... ... ..................... ....................... .... .. 33 Cryptographic Algorithm Agility ........ .... ... .. .......... ... ..... ... .. .......... ...... ... ........ .. .... .. .... ............... .... .. .... .. .. .. .. 33 Cryptographic Agility Overview ............. .. ........ ......................................................................................... 33 Requirements i~t~~;~· c~~t~~i :: ::::: :: :: :: : : :: ::: : :: : :: ::: :: : ::: : :: :: : : :: :: ::: : : :: :: : ::: :::::: :: :: :: :: : :: : :: : :: : :: ::: ::: : :: :: : : :: :: : ::: : :: ::: :: : :: : :: : :: : : :: :: :: :::: 34 33 Interface Control Overview .............. ............... ......................................................................................... 34 Requirements ............................................................................................................................ ............... 34 Secure Execution Environment........ ..... .... .. .... ............. .. .... .... ........ .. ............. .... .. ...... ... ............................ 36 Secure Execution Environment Basics: Required ................................................................................... 36 Requirements... ... ..... .. .. .... ...... ..... ........ ...... .... .. ... .... ........... ... .... ..... ... ... ..... ....... .... .... ............... ... ....... .. ...... 36 Implementation Considerations (Informative) ........... ............... .............. ............... ............... .. .. .. .............. 37 Self-Test .... .......................................... ...... ......... ....... ............. .. .... ..... .. ............ .. .................. ...... .... ... ........ 38 Operational States: Conditional ............................................................................................................... 38 Self-Test Overview .......... ....... ... ................. ... ..................................................... ...................................... 39 Requirements ... ............ ... ... ...... ....................... ...... ... ........................ ......................... .. .................. ..... ...... 40 7. 7.1 7.2 7.3 ; : 7.6 7.7 PROFILES OF HARDWARE SECURITY COMMON REQUIREMENTS …………..……………………………. 41 Confidentiality Profile ...................................... ......................................................................................... 42 Integrity Profile ......... .. .. .... .. ... .... ....... .... ..... .. .... .... ... ........ .... .. .... .. ...... ... ........ .. .... .... .. ..................... .... .. .. .. .. 43 Availability Profile ..................................................................................................................................... 43 $cn？盓芦d~；巠心~ri;~~I~·::::: : :: : :: ::: ::: ::: :: : : :: :: : : ::::: ::: :: : :: : : :: :: : : :: :: :: :: :: : ::: :: : :: ::: ::: :: :: :: :: : : :: :: : : :: ::: ::: :: ::: : : :: :: : : :: : ::: :: :: :~ Limited Use .................. .. ........ .. ........ ..... .......... .................................. .. ... ..... .. .. .. .. .... .. .. ...... .. ...... ..... .......... 44 Assurance Level (Informative) ................................................................................................................. 44 8. VALIDATION AND VERIFICATION ........... .... .. ... ... ........ ........................................... ............................. .. 45 9. 9: 1 9.1.1 9.1.2 9.1.3 9.1.4 9.1.5 2 ; 6 9.2.1 9.2.2 9.2.3 9.2.4 ii5 PRIMARY USE CASES A~t·h·;~ti~~t;d s;~t~.~~.::: :: : :: : :: : :: ::: ::: :: : : :: :: : : ::::: ::: ::: :: : ::::::: :: :: :: :: :: : ::: :: : :: ::: ::: :: :: :: :: : : :: :: : ::: ::: ::: ::::::: :: :: : : :: :::: :: :: 4s 45 Objectives ...... .. ...................................................................................... ...... ..... .. ...... .......... ..................... 45 Scope and Definitions .............................................................................................. ................................ 45 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::46 Illustrative Process Requirements ... ... ......... ......... ........... ............... ........................... ........ ...... ....... .. ................ ....... .... ............ 46 Implementation Considerations ..... ..... .... .. .. ................... .. ...................... ......... .... .. ................................... 4 7 :ue$）e网心ea?:：＄氐°af心~~:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ．名 Objectives ..... ... ........ .. .. .... .... ..................... .... .. ... .......................... ....... ... ... ... ... .... .... ............ ... .... ... ........... 48 Assumptions for Delivery of Firmware ..................................................................................................... 48 Scope and Definitions .. .... ...... .. ........... .. .. .. .... .. ....... ........ ... ... .... .. .... .. ... ... ... .. .. .. .... .... ................... .. .... .. .. .. .. 48 Illustrative Process ... .. .. .. ........ .. ........ ... .. ........ .. .... ... ........ ... ..... ..... ...... .. ... ..... .. ............ .. ........ ..................... 49 R;~~;;;;e.nt;~~~~. ::: :: :: :: : : :: : :: : :: : :: ::: :: : ::: : :: :: : : :: :: : ::: :: : :: : :: : :: ::: : :: :: :: :: : :::::: :: ::: :: : :::: :: :: : : :: :: : ::: ::: ::: :: : :: : ::: :: : : :: :: :: :::: 50

SAE INTERNATIONAL J3101 TM FEB2020 Page 3 of 80 9.2.6 9.2.7 9.3 9.3.1 9.3.2 9.3.3 9.3.4 ;:~:: i4:3 9.4 9.4.1 9.4.2 9.4.4 9.4.5 9.4.6 9.5 is.1 9.5.2 9.5.3 9.5.4 9.5.5 9.5.6 Access Mechanisms .............. .................................................................................................................. 54 Objectives ........................................ ...................................................... ....... .............. ..... ...... ................ .. 54 Scope .. Implementation Considerations 51 Recommended Profile(s) ......................................................................................................................... 52 Secure In-Vehicle Messaging .................................................................................................................. 52 Objectives Scooe and Definitions ..................................... ....................... .............. ... ................................................. 52 Requirements ................................... ................................................................................... .... ................. 52 Implementation Considerations R~;;,:,·;·~·;d;d· P~t~~(;)~.-.-~:.·~.::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: s;~p;--~~d ·o~ti~iii~-~-~·:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 52 t~~;;;t~;~~ ~~~~~~=)~~.i~~~. :: ::: :: : ::: : :: :: : : :: :: : ::: ::: :: : :: : :: :::: :: :: :: :: : :: : :: : :: : :: ::: :::: :: :: : : :: :: : : :: : : : ::: :: : :: : ::: :: : : :: :: :: :::: ;~ R;~~ir~~~~i~:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ss 54 R~;;,:,·;·~·;d;d· P~t~~(;)~.-.·~:.·~.::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: otiT;~tiv;~-:~~.~.::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::6s R;q~ir;~;;;::·.:·.:·.~.·.·.~.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: R~;;,:,·;·~·;d;d· P~t~~(;) ~.-.-~:.'~. :: ::: :: : :: : : :: :: : : ::::: ::: :: : :: : ::: :: : : :: :: :: :: :: : :: : :: : :: ::: ::: :: :: :: :: : : :::::: :: ::: ::: ::: :: : : :: :: : : :: :::: :: :: Scope and Definitions 65 Reauirements ........................................................................................................................................... 65 Illustrative Process ................. ......................... ....................... .............. .................................................... 66 Implementation Considerations 67 Recommended Profile(s) ......................................................................................................................... 68 Illustrative Processes ............................................................................................................................... 56 Implementation Considerations 62 Recommended Profile(s) ....... .................................................................................................................. 65 Secure Storage ........................................................................................................................................ 65 10. 1 0. 1 10.1.1 APPLICATION USE CASES 68 IntelIectuaI Property Protecti65厂：：：：．：：：：：：：：：．：：：：：：：：：：：：：：：：:::::::::::::::: ：：厂厂：：：：：．．：：：：：：：：：：：：：：：：：．，厂：：：：：：：::: ::::::::::: :: :::::::: 68 Objectives .............................. ................................................................................................... ............... 68 器｝云吕ce:：？rea$:n气：~~~~i·~·~·~·:.:::::::.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ;; 10.1 .4 10.1.5 10.2 10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 Implementation Considerations.. ... ....... .... .... .. .... ... ..... ... .... .. .... ........ ... ... ..... .. .. .... .... ............... .. .... .. .... .... .. 69 Recommended Profile(s) ....... ........... .............. .......... .................. ........... ..... .. .................... ........ ......... ...... 69 Secure Diagnosis at the ECU Level.................... ... ................................ ................... ......................... .... .. 69 Objectives .............................. ............................................................................................. .... ................. 69 Scope and Definitions c~;;;~·R;q~·i;~;;;~~t~·::: :: : :: : :: : :: ::: :: : ::: : :: :: : : :: :: : ::: :: : :: : :: ::: : :: : :: :: :: :: : :: ::: : :: ::: ::: :: :: :: :: : : :: :: : : :: ::: ::: :: : :: : :: : :: :: :: :: :: :::: 69 Common Reauirements ........................................................................................................................... 70 Illustrative Process 71 R;~~;-~;~d;d-Pr~t1i~~:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Recommended Profiles.... ...... ... ............ .... .. .... .... ........ ... .... ...... .. ...... ... ... ....... .. .... ...... ..... ..... ... .. .... .... ...... .. 73 ~言乙詈．~i.~.~.::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::．旮 Scope and Definitions ............ ................................................................ ................... ............................... 7 4 Common Requirements ................... ................................................................................... ..................... 74 Illustrative Process Recommended Profiles.................. ............. .... ............... .................... ............. ...... .... ........ ............ ........... 76 R;~~;-~;~d;d-Pr~t1i~~ :: : : :: : :: : :: ::: ::: ::: :: : : :: :: : : ::::: ::: :: : :: : ::: :: : : :: :: :: :: :: : ::: :: : :: ::: ::: :: :: :: :: : : :: :: : : :: ::: ::: :: ::: : : :: :: : : :: :::: :: :: 75 ~笃~;~-i~d;~~-i~;::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: jj APPENDIX A EXAMPLES OF ENTROPY AND DETERMINISTIC BIT GENERATORS …·……..……………………………. 78 ~ ~:1 ~~:~. 1 10.3.2 10.3.3 10.3.4 10.3.5 Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Hardware protected security environment abstraction layers ......................... ... ....... ..................... .......... 11 Key management and provisioning ........................................................................... ............................... 14 Digital signature process .................................. ．舍．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 50 Example update flow b y service technician ........ ......... .... .............. .... ............... ................... .............. .... .. 58 Access control - fully hardware protected security environment controlled .………·…………………………… . 63 Access control - partial hardware protected security environment control ...….........……………..………….. 64 Authorization flow for secure diagnostics ...... ...... ......... .... .... .... ........ ..... .......... .......... ............. .. .... .......... .. 71 Table 1 C ommon requirements of each profile ..................................................................................................... 42

SAE INTERNATIONAL J3101 TM FEB2020 Page 4 of 80 1. INTRODUCTION Automotive computer systems are required to establish trustworthiness through device identity, sealing, attestation, data integrity, and availability. These systems must be res 小 ent to a wide range of attacks that cannot be thwarted through software-only security mechanisms. A hardware root of trust and the hardware-based security primitives are fundamentally necessary to satisfy demands of connected and highly or fully automated vehicles. This document provides a comprehensive view of security mechanisms supported in hardware for automotive use cases, along with best practices for using such mechanisms. The goal of this document is to provide a common reference that facilitates communication among engineers across different parts of the automotive supply chain relevant to hardware-enabled security features. Silicon vendors will find this document useful in understanding the hardware security foundations and their corresponding use cases and applications that they should support to address vehicle security needs. This document should also bring more order into the diverse nature of hardware security features, so products are developed with the end use case in mind and with the right level of security. ECU suppliers and system integrators will benefit from the different security requirements and use cases outlined here as they assess the threats that affect their systems and the right hardware systems needed to address them . This document represents a collection of characteristics of hardware mechanisms that are of use to, and address the needs of, the automotive industry in order to provide insight to the silicon industry and prevent fragmentation. There exists a demand in the auto industry for a document to provide a baseline of due diligence in product development. This document aims to meet that need as a reference of industry best practices of minimum expectations of hardware protected cybersecurity. 1.1 Scope and Objective This document presents a common set of requirements to be implemented in hardware-assisted functions to facilitate security-enhanced applications, to achieve an ideal system for hardware protection for ground vehicle applications. This document will outline a common set of requirements to meet this goal and illustrate examples of the use of such requirements in various use cases which span the lifecycle of ground vehicle products, without explicitly detailing implementation requirements. SAE J3101 has taken the approach of defining requirements through fundamental use cases. These requirements become building blocks for innovation, but are not development-process oriented. The presented building blocks are not attempting to encompass all future potential innovation; however, considerable future innovation should be possible through creative combinations of the presented requirements. It should be expected that some innovation may create future core requirements that themselves become new building blocks not captured within the scope of this revision of this document 1.2 Audience This standard is written from the point of view of automakers and suppliers to automakers addressed to embedded component suppliers such as microcontroller vendors . Although consumer automobile applications dominate the illustrated use cases the document is intended to apply to any ground vehicle application. Government applications suggested within this document are "non-tactical" characterized as otherwise civilian vehicles repurposed for government purposes. This document specifically does not include use cases of military applications

SAE INTERNATIONAL J3101 TM FEB2020 Page 5 of 80 2. REFERENCES 2.1 Applicable Documents The following publications form a part of this specification to the extent specified herein. Unless otherwise indicated, the latest issue of SAE publications shall apply. 2.1 .1 SAE Publications Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001 , Tel: 877-606-7323 (inside USA and Canada) or +1 724-776-4970 (outside USA), ~ - SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems 2.1.2 ISO Publications Copies of these documents are available online at ~ l. 1S0/IEC 2382:2015 Information Technology - Vocabulary 1S0/IEC/IEEE DIS 8802-1 AE Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Part 1AE: Media Access Control (MAC) Security 1S0/IEC 9797-1 :2011 Information Technology - Security Techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms Using A Block Cipher 1S0/IEC 9797-2:2011 Information Technology - Security Techniques - Message Authentication Codes (MACs) - Part 2: Mechanisms Using a Dedicated Hash-Function 1S0/IEC 10116:2017 Information Technology - Security Techniques - Modes of Operation for an N-Bit Block Cipheriso 15782-1 :2009 1S0/IEC 17025:2017 General Requirements for the Competence of Testing and Calibration Laboratories ISO 18031 :2011 Information Technology - Security Techniques - Random Bit Generation 1S0/IEC 18033-3:2010 Information Technology - Security Techniques - Encryption Algorithms - Part 3: Block Ciphersiso 19772 ISO/IEC 19790:2012 Information Technology - Security Techniques - Security Requirements for Cryptographic Modulesiso/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

SAE INTERNATIONAL J3101 TM FEB2020 Page 6 of 80 2.1 .3 NIST Publications Available from NIST, 100 Bureau Drive, Stop 1070, Gaithersburg, MD 20899-1070, Tel: 301-975-6478, ~ - 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: the CMAC Mode for Authentication (May 2005) NIST SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality (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: the XTS-AES Mode for Confidentiality on Storage Devices (January 2010) NIST SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping (December 2012) NIST SP 800-47 Security Guide for Interconnecting Information Technology Systems (August 2002) NIST 800-53A Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans (December 2014) NIST SP 800-57 Part 1, Rev. 4: Recommendation for Key Management, Part 1: General (January 2016) SP 800-90A SP 800-90B SP 800-90C Rev. 1: Recommendation for Random Number Generation Using Deterministic Random Bit Generators (June 2015) Recommendation for the Entropy Sources Used for Random Bit Generation (January 2018) [draft] Recommendation for Random Bit Generator (RBG) Constructions (April 2016) NIST SP 800-131A Rev. 2: Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019) NIST IR 7316 Assessment of Access Control Systems (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 The 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)

SAE INTERNATIONAL J3101 TM FEB2020 Page 7 of 80 Cryptographic Algorithm Validation Program (CAVP) htt s:I/csrc.nist. ov/ rOects/c to ra hic-aI orithm-va|idation- ro ram Cryptographic Module Validation Program (CMVP) https://csrc.n_ist.gov/p_roiectsJc_ryJ)tograpbic-module-validation-1xoi:iram Interoperable Randomness Beacons htt~erable-randomness-beacons Entropy as a Service https:IIcsrc.nist.qov/proiects/entropy-as-a-servIce NISTCAVP - Cryptographic Algorithm Validation Program httos://csrc.nist.aov/oroiects/crvotoaraohic-alaorithm-validation-oroaram/validation NISTDRBG - Cryptographic Algorithm Validation Program (DRBG) httos://csrc.nist.aov/oroiects/crvotoaraohic-alaorithm-validation-oroaram/validation/validation-list/drb NISTRNG- CryptographlCAIgorithm Vahdahon Program (RNG) httos://csrc.nist.aov/oroiects/crvotoaraohic-alaorithm-validation-oroaram/validation/validation-list/rn 2.1.3.1 IETF Publications Copies of these documents are available online at~ / RFC 7696 RFC 4949 RFC 6979 RFC 8391 RFC 7905 RFC 8439 RFC 7748 RFC 8032 RFC 8554 RFC 8125 Guidelines Algorithms for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Internet Security Glossary, Version 2 (August 2007) Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (August 2013) XMSS : extended Merkle Signature Scheme (May 2018) ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) (June 2016) ChaCha20 and Poly1305 for IETF Protocols (June 2018) Elliptic Curves for Security (January 2016) Edwards-Curve Digital Signature Algorithm (EdDSA) (January 2017) Leighton-Micali Hash-Based Signatures (April 2019) Requi 「ements for PAKE Schemes (April 2017) 2.1.3.2 IEEE Publications Available from IEEE Operations Center, 445 and 501 Hoes Lane, Piscataway, NJ 08854-4141 , Tel: 732-981-0060, www.ieee.orq. IEEE 1609.2-2016 Wireless Access Management Messages in Vehicular Environments-Security Services for Applications and IEEE 1619-2018 Cryptographic Protection of Data on Block-Oriented Storage Devices

SAE INTERNATIONAL J3101 TM FEB2020 Page 8 of 80 2.1.4 Other Publications 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 Standard for Design and Implementation," 2019. ITU-T X.509, "Information Technology- Open Systems Interconnection- The Directory: Public-Key and Attribute Certificate Frameworks," International Telecommunication Union, October 2016 , 旦但S 扒胜凶W. itu.int/rec/T-REC-X . 509 . BSI AIS 20/31 , "Evaluation of Random Number Generators," Bundesamt fur Sicherheit in der lnformationstechnik, httos ://www. bsi. bund.de/SharedDocs/Downloads/DE/BS 1/Zertifizieruna/lnteroretationen/ Al S 20 Al S 31 Evaluation of ra ndom number ~df. 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 , 旦垃 //cacr. uwaterloo . ca/hac/. 44 U.S.C., Sec. 3542: Title 44 United States Code Section 3542 - "Definitions." Blake-Wilson, S., Menezes, A., "Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol," Lecture Notes in Computer Science, 1560, Springer, 154-170, 1999. Dan Kaminsky "Black Ops" Blog, ~om12Q12/Q81Q61bQ2Q12L - 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:~172. [PQC_NIST] Dustin Moody, The ship has sailed: The NIST Post-Quantum Crypto "Competition," NIST. TCG TPM 2.0 Library r1 .38, (February, 2017), ~ Architecture-01 .38.Qdf. loads/TPM-Rev-2.0-Part-1- Weimerskirch htto://www.embedded.com/desian/confiaurable-svstems/4008264/3/Usina-software-f1ashina-to-secure-embedded-device updates. embedded software Schramm, "Using to secure and flashing device updates," 3. DEFINITIONS The following provides further refinement of definitions of terms for the purpose of SAE J3101 . ACCESS CONTROL: Obtaining the use of a resource (ISO/IEC 2382:2015). Access control is concerned with determining the allowed activities of legitimate users, mediating every attempt by a user to access a resource in the system, thus protecting system resources against inappropriate or undesired user access (NIST: Assessment of Access Control Systems). ASSET: Anything that has value to the product's stakeholders. Assets can be tangible or intangible. Examples of tangible assets are ECUs, sensors, or actuators. Examples of intangible assets are reputation, or intellectual property (ISO 21434 (draft)). AUTHENTICATION: A provision of assurance that a claimed characteristic of an entity is correct (ISO 27000:2016). AUTHORIZATION: Granting of rights (ISO 15782-1 :2009). CRITICAL SECURITY PARAMETERS (CSP): Contain security-related information (e.g. , counte 「s , authentication data such as passwords and personal identification numbers (PINs)) whose disclosure or modification can compromise the security of a cryptographic operation (FIPS 140-2) CRYPTO AGILITY: The ability to migrate from one implemented algorithm suite to another over time (RFC 7696).

分享到：

赞收藏

资料库

SAE-2020-J3101-硬件安全标准.pdf

相关推荐

安全技术

热门标签

最新资料