DOCSLIB.ORG

TCG Algorithm Registry Family “2.0”

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
TCG Algorithm Registry Family “2.0” TCG Algorithm Registry Family “2.0" Level 00 Revision 01.32 June 25, 2020 Contact: [email protected] TCG PUBLISHED TCG Copyright © TCG 2020 TCG Algorithm Registry Disclaimers, Notices, and License Terms THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification and to the implementation of this specification, and TCG disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any way out of use or reliance upon this specification or any information herein. This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted herein other than as follows: You may not copy or reproduce the document or distribute it to others without written permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG specifications or (b) developing, testing, or promoting information technology standards and best practices, so long as you distribute the document with these disclaimers, notices, and license terms. Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing through membership agreements. Any marks and brands contained herein are the property of their respective owners. Page ii TCG PUBLISHED Family “2.0" June 25, 2020 Copyright © TCG 2020 Level 00 Revision 01.32 TCG Algorithm Registry Change History Version Date Description 1.27 09.26.2017 Added change history. CMAC algorithm assigned as 0x003F in Table 3. Removed extra whitespace above the title of clause 6.10. Assigned bitfields in Table 25 for SHA3_256, SHA3_384 and SHA3_512. Replaced references of deprecated IETF 3447 with IETF 8017. Removed Annex A (Applicability of this Registry for Other TCG Specifications) 1.28 01.28.2020 Removed Type “H” for TPM_ALG_OAEP in Table 3 Added Types “E” and “M” and comments for TPM_ALG_SM2 in Table 3 Changed references for SM2 to GB/T 32918 Parts 1 through 5 Changed reference for SM3 to ISO/IEC 10118-3:2018 Changed reference for SM4 to GB/T 32907-2016 1.29 02.19.2020 Added algorithms CCM, GCM, KW, KWP, EAX, EdDSA in Table 3 Added Brainpool P256/384/512 R1 curves in Table 4 Added curve parameters for Brainpool P256/384/512 R1 to clause 5.2 Added curve parameters for Curve 25519 to clause 5.2 1.30 02.27.2020 Added 2nd reference to TPM_ALG_ECDH in Table 3 to include X25519 Added note to TPM_ALG_EDDSA in Table 3 1.31 03.09.2020 Updated EDDSA to EdDSA in Table 4 Fixed formatting in Table 5, NIST_P192, parameter value of gY Fixed formatting in Table 10, BN_P256, parameter value of p and n Fixed formatting in Table 18, 19, 20 1.32 03.20.2020 Added new references to bibliography Family “2.0" TCG PUBLISHED Page iii Level 00 Revision 01.32 Copyright © TCG 2020 June 25, 2020 TCG Algorithm Registry CONTENTS 1 Introduction .......................................................................................................................... 1 2 Conventions ......................................................................................................................... 2 2.1 Bit and Octet Numbering and Order ........................................................................... 2 2.2 Sized Buffer References ............................................................................................ 2 2.3 Numbers .................................................................................................................... 3 3 Notation ................................................................................................................................ 4 3.1 Named Constants ....................................................................................................... 4 3.2 Enumerations ............................................................................................................. 4 3.3 Bit Field Definitions .................................................................................................... 5 3.4 Name Prefix Convention ............................................................................................. 5 4 TPM_ALG_ID ....................................................................................................................... 6 5 ECC Values ........................................................................................................................ 11 5.1 Curve ID Values ....................................................................................................... 11 5.2 Curve Parameters .................................................................................................... 12 5.2.1 Introduction ..................................................................................................... 12 5.2.2 NIST P192 ...................................................................................................... 12 5.2.3 NIST P224 ...................................................................................................... 13 5.2.4 NIST P256 ...................................................................................................... 14 5.2.5 NIST P384 ...................................................................................................... 15 5.2.6 NIST P521 ...................................................................................................... 16 5.2.7 BN P256 ......................................................................................................... 17 5.2.8 BN P638 ......................................................................................................... 18 5.2.9 SM2_P256 ...................................................................................................... 19 5.2.10 BP_P256_R1 .................................................................................................. 20 5.2.11 BP_P384_R1 .................................................................................................. 21 5.2.12 BP_P512_R1 .................................................................................................. 22 5.2.13 CURVE_25519 ................................................................................................ 23 6 Hash Parameters ................................................................................................................ 24 6.1 Introduction .............................................................................................................. 24 6.2 SHA1 ....................................................................................................................... 24 6.3 SHA256 ................................................................................................................... 24 6.4 SHA384 ................................................................................................................... 24 6.5 SHA512 ................................................................................................................... 25 6.6 SM3_256.................................................................................................................. 25 6.7 SHA3_256 ................................................................................................................ 25 6.8 SHA3_384 ................................................................................................................ 25 6.9 SHA3_512 ................................................................................................................ 26 6.10 Hash Algorithms Bit Field ......................................................................................... 26 7 Symmetric Block Cipher Parameters ................................................................................... 27 7.1 Introduction .............................................................................................................. 27 7.2 AES ......................................................................................................................... 27 7.3 SM4 ......................................................................................................................... 27 7.4 Camellia ................................................................................................................... 27 7.5 TDES ....................................................................................................................... 28 Annex A — Bibliography ............................................................................................................ 29 Page iv TCG PUBLISHED Family “2.0" June 25, 2020 Copyright © TCG 2020 Level 00 Revision 01.32 TCG Algorithm Registry TCG Algorithm Registry 1 Introduction The Algorithm Registry lists each algorithm assigned an identifier, allowing it to be unambiguously defined and referenced by other TCG specifications. This document is a compendium of data related to the various algorithms used in specifications created by the Trusted Computing Group (TCG). The compendium of algorithm data is intended to ensure interoperability between
Load more

Recommended publications
  • Correlation Power Attack on a Message Authentication Code Based on SM3∗
    930 Yuan et al. / Front Inform Technol Electron Eng 2019 20(7):930-945 Frontiers of Information Technology & Electronic Engineering www.jzus.zju.edu.cn; engineering.cae.cn; www.springerlink.com ISSN 2095-9184 (print); ISSN 2095-9230 (online) E-mail: [email protected] Correlation power attack on a message authentication code based on SM3∗ Ye YUAN†1,2,Kai-geQU†‡1,2,Li-jiWU†‡1,2,Jia-weiMA3, Xiang-min ZHANG†1,2 1Institute of Microelectronics, Tsinghua University, Beijing 100084, China 2National Laboratory for Information Science and Technology, Tsinghua University, Beijing 100084, China 3State Key Laboratory of Cryptography, Beijing 100094, China †E-mail: [email protected]; [email protected]; [email protected]; [email protected] Received May 19, 2018; Revision accepted July 30, 2018; Crosschecked July 12, 2019 Abstract: Hash-based message authentication code (HMAC) is widely used in authentication and message integrity. As a Chinese hash algorithm, the SM3 algorithm is gradually winning domestic market value in China. The side channel security of HMAC based on SM3 (HMAC-SM3) is still to be evaluated, especially in hardware implementa- tion, where only intermediate values stored in registers have apparent Hamming distance leakage. In addition, the algorithm structure of SM3 determines the difficulty in HMAC-SM3 side channel analysis. In this paper, a skillful bit-wise chosen-plaintext correlation power attack procedure is proposed for HMAC-SM3 hardware implementation. Real attack experiments on a field programmable gate array (FPGA) board have been performed. Experimental results show that we can recover the key from the hypothesis space of 2256 based on the proposed procedure.
    [Show full text]
  • Post-Quantum Cryptography
    Post-quantum cryptography Daniel J. Bernstein & Tanja Lange University of Illinois at Chicago; Ruhr University Bochum & Technische Universiteit Eindhoven 12 September 2020 I Motivation #1: Communication channels are spying on our data. I Motivation #2: Communication channels are modifying our data. I Literal meaning of cryptography: \secret writing". I Achieves various security goals by secretly transforming messages. I Confidentiality: Eve cannot infer information about the content I Integrity: Eve cannot modify the message without this being noticed I Authenticity: Bob is convinced that the message originated from Alice Cryptography with symmetric keys AES-128. AES-192. AES-256. AES-GCM. ChaCha20. HMAC-SHA-256. Poly1305. SHA-2. SHA-3. Salsa20. Cryptography with public keys BN-254. Curve25519. DH. DSA. ECDH. ECDSA. EdDSA. NIST P-256. NIST P-384. NIST P-521. RSA encrypt. RSA sign. secp256k1. Cryptography / Sender Receiver \Alice" \Bob" Tsai Ing-Wen picture credit: By =q府, Attribution, Wikimedia. Donald Trump picture credit: By Shealah Craighead - White House, Public Domain, Wikimedia. Daniel J. Bernstein & Tanja Lange Post-quantum cryptography2 Cryptography with symmetric keys AES-128. AES-192. AES-256. AES-GCM. ChaCha20. HMAC-SHA-256. Poly1305. SHA-2. SHA-3. Salsa20. I Literal meaning of cryptography: \secret writing". Cryptography with public keys Achieves various security goals by secretly transforming messages. BN-254I . Curve25519. DH. DSA. ECDH. ECDSA. EdDSA. NIST P-256. NIST P-384. Confidentiality: Eve cannot infer information about the content NISTI P-521. RSA encrypt. RSA sign. secp256k1. I Integrity: Eve cannot modify the message without this being noticed I Authenticity: Bob is convinced that the message originated from Alice Cryptography / Sender Untrustworthy network Receiver \Alice" \Eve" \Bob" I Motivation #1: Communication channels are spying on our data.
    [Show full text]
  • On the Design and Performance of Chinese OSCCA-Approved Cryptographic Algorithms Louise Bergman Martinkauppi∗, Qiuping He† and Dragos Ilie‡ Dept
    On the Design and Performance of Chinese OSCCA-approved Cryptographic Algorithms Louise Bergman Martinkauppi∗, Qiuping Hey and Dragos Iliez Dept. of Computer Science Blekinge Institute of Technology (BTH), Karlskrona, Sweden ∗[email protected], yping95 @hotmail.com, [email protected] Abstract—SM2, SM3, and SM4 are cryptographic standards in transit and at rest [4]. The law, which came into effect authorized to be used in China. To comply with Chinese cryp- on January 1, 2020, divides encryption into three different tography laws, standard cryptographic algorithms in products categories: core, ordinary and commercial. targeting the Chinese market may need to be replaced with the algorithms mentioned above. It is important to know beforehand Core and ordinary encryption are used for protecting if the replaced algorithms impact performance. Bad performance China’s state secrets at different classification levels. Both may degrade user experience and increase future system costs. We present a performance study of the standard cryptographic core and ordinary encryption are considered state secrets and algorithms (RSA, ECDSA, SHA-256, and AES-128) and corre- thus are strictly regulated by the SCA. It is therefore likely sponding Chinese cryptographic algorithms. that these types of encryption will be based on the national Our results indicate that the digital signature algorithms algorithms mentioned above, so that SCA can exercise full SM2 and ECDSA have similar design and also similar perfor- control over standards and implementations. mance. SM2 and RSA have fundamentally different designs. SM2 performs better than RSA when generating keys and Commercial encryption is used to protect information that signatures. Hash algorithms SM3 and SHA-256 have many design similarities, but SHA-256 performs slightly better than SM3.
    [Show full text]
  • Secure Authentication Protocol for Internet of Things Achraf Fayad
    Secure authentication protocol for Internet of Things Achraf Fayad To cite this version: Achraf Fayad. Secure authentication protocol for Internet of Things. Networking and Internet Archi- tecture [cs.NI]. Institut Polytechnique de Paris, 2020. English. NNT : 2020IPPAT051. tel-03135607 HAL Id: tel-03135607 https://tel.archives-ouvertes.fr/tel-03135607 Submitted on 9 Feb 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Protocole d’authentification securis´ e´ pour les objets connectes´ These` de doctorat de l’Institut Polytechnique de Paris prepar´ ee´ a` Tel´ ecom´ Paris Ecole´ doctorale n◦626 Ecole´ doctorale de l’Institut Polytechnique de Paris (EDIPP) Specialit´ e´ de doctorat : Reseaux,´ informations et communications NNT : 2020IPPAT051 These` present´ ee´ et soutenue a` Palaiseau, le 14 decembre´ 2020, par ACHRAF FAYAD Composition du Jury : Ken CHEN Professeur, Universite´ Paris 13 Nord President´ Pascal LORENZ Professeur, Universite´ de Haute-Alsace (UHA) Rapporteur Ahmed MEHAOUA Professeur, Universite´ Paris Descartes Rapporteur Lyes KHOUKHI Professeur, Ecole´ Nationale Superieure´ d’Ingenieurs´ de Examinateur Caen-ENSICAEN Ahmad FADLALLAH Associate Professor, University of Sciences and Arts in Lebanon Examinateur (USAL) Rida KHATOUN Maˆıtre de conferences,´ Tel´ ecom´ Paris Directeur de these` Ahmed SERHROUCHNI Professeur, Tel´ ecom´ Paris Co-directeur de these` Badis HAMMI Associate Professor, Ecole´ pour l’informatique et les techniques Invite´ avancees´ (EPITA) 626 Acknowledgments First, I would like to thank my thesis supervisor Dr.
    [Show full text]
  • Alternative Elliptic Curve Representations
    Alternative Elliptic Curve Representations draft-struik-lwig-curve-representations-00 René Struik Struik Security Consultancy E-mail: [email protected] IETF 101draft-struik – London,-lwig-curve- representationsUK, March-002018 1 Outline 1. The ECC Algorithm Zoo – NIST curve P-256, ECDSA – Curve25519 – Ed25519 2. Implementation Detail 3. How to Reuse Code 4. How to Reuse Existing Standards 5. Conclusions draft-struik-lwig-curve-representations-00 2 ECC Algorithm Zoo (1) NIST curves: Curve model: Weierstrass curve Curve equation: y2 = x3 + ax + b (mod p) Base point: G=(Gx, Gy) Scalar multiplication: addition formulae using, e.g., mixed Jacobian coordinates Point representation: both coordinates of point P=(X, Y) (affine coordinates) 0x04 || X || Y in most-significant-bit/octet first order Examples: NIST P-256 (ANSI X9.62, NIST SP 800-56a, SECG, etc.); Brainpool256r1 (RFC 5639) ECDSA: Signature: R || s in most-significant-bit/octet first order Signing equation: e = s k + d r (mod n), where e=Hash(m) Example: ECDSA, w/ P-256 and SHA-256 (FIPS 186-4, ANSI X9.62, etc.) Note: message m pre-hashed draft-struik-lwig-curve-representations-00 3 ECC Algorithm Zoo (2) CFRG curves: Curve model: Montgomery curve Curve equation: By2 = x3 + Ax2 + x (mod p) Base point: G=(Gx, Gy) Scalar multiplication: Montgomery ladder, using projective coordinates [X: :Z] Point representation: x-coordinate of point P=(X, Y) (x-coordinate-only) X in least-significant-octet, most-significant-bit first order Examples: Curve25519, Curve448 (RFC 7748) DH Key agreement:
    [Show full text]
  • Security Analysis of the Signal Protocol Student: Bc
    ASSIGNMENT OF MASTER’S THESIS Title: Security Analysis of the Signal Protocol Student: Bc. Jan Rubín Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security Department: Department of Computer Systems Validity: Until the end of summer semester 2018/19 Instructions 1) Research the current instant messaging protocols, describe their properties, with a particular focus on security. 2) Describe the Signal protocol in detail, its usage, structure, and functionality. 3) Select parts of the protocol with a potential for security vulnerabilities. 4) Analyze these parts, particularly the adherence of their code to their documentation. 5) Discuss your findings. Formulate recommendations for the users. References Will be provided by the supervisor. prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague January 27, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Computer Systems Master’s thesis Security Analysis of the Signal Protocol Bc. Jan Rub´ın Supervisor: Ing. Josef Kokeˇs 1st May 2018 Acknowledgements First and foremost, I would like to express my sincere gratitude to my thesis supervisor, Ing. Josef Kokeˇs,for his guidance, engagement, extensive know- ledge, and willingness to meet at our countless consultations. I would also like to thank my brother, Tom´aˇsRub´ın,for proofreading my thesis. I cannot express enough gratitude towards my parents, Lenka and Jaroslav Rub´ınovi, who supported me both morally and financially through my whole studies. Last but not least, this thesis would not be possible without Anna who re- lentlessly supported me when I needed it most. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.
    [Show full text]
  • Multi-Party Encrypted Messaging Protocol Design Document, Release 0.3-2-Ge104946
    Multi-Party Encrypted Messaging Protocol design document Release 0.3-2-ge104946 Mega Limited, Auckland, New Zealand Guy Kloss <[email protected]> arXiv:1606.04593v1 [cs.CR] 14 Jun 2016 11 January 2016 CONTENTS 1 Strongvelope Multi-Party Encrypted Messaging Protocol 2 1.1 Intent.......................................... ....... 2 1.2 SecurityProperties.............................. ............ 2 1.3 ScopeandLimitations ............................. ........... 3 1.4 Assumptions ..................................... ........ 3 1.5 Messages........................................ ....... 3 1.6 Terminology ..................................... ........ 4 2 Cryptographic Primitives 5 2.1 KeyPairforAuthentication . ............. 5 2.2 KeyAgreement.................................... ........ 5 2.3 (Sender)KeyEncryption. ............ 5 2.4 MessageAuthentication . ............ 6 2.5 MessageEncryption ............................... .......... 6 3 Message Encryption 7 3.1 SenderKeyExchange ............................... ......... 7 3.2 ContentEncryption............................... ........... 8 4 Protocol Encoding 9 4.1 TLVTypes ........................................ ...... 9 4.2 MessageSignatures ............................... .......... 10 4.3 MessageTypes.................................... ........ 10 4.4 KeyedMessages ................................... ........ 10 4.5 FollowupMessages ................................ ......... 10 4.6 AlterParticipantMessages. .............. 11 4.7 LegacySenderKeyEncryption . ............ 11 4.8 SenderKeystoInclude...
    [Show full text]
  • Practical Fault Attack Against the Ed25519 and Eddsa Signature Schemes
    Practical fault attack against the Ed25519 and EdDSA signature schemes Yolan Romailler, Sylvain Pelissier Kudelski Security Cheseaux-sur-Lausanne, Switzerland fyolan.romailler,[email protected] main advantages is that its scalar multiplication can be Abstract—The Edwards-curve Digital Signature Algorithm implemented without secret dependent branch and lookup, (EdDSA) was proposed to perform fast public-key digital avoiding the risk of side-channel leakage. More recently, a signatures as a replacement for the Elliptic Curve Digital Signature Algorithm (ECDSA). Its key advantages for em- new digital signature algorithm, namely Ed25519 [6], was bedded devices are higher performance and straightforward, proposed based on the curve edwards25519, i.e., the Edward secure implementations. Indeed, neither branch nor lookup twist of Curve25519. This algorithm was then generalized operations depending on the secret values are performed to other curves and called EdDSA [7]. Due to its various during a signature. These properties thwart many side-channel advantages [7], EdDSA was quickly implemented in many attacks. Nevertheless, we demonstrate here that a single-fault attack against EdDSA can recover enough private key material products and libraries, such as OpenSSH [8]. It was also to forge valid signatures for any message. We demonstrate a recently formally defined in RFC 8032 [9]. practical application of this attack against an implementation The authors of EdDSA did not make any claims about its on Arduino Nano. To the authors’ best knowledge this is the security against fault attacks. However, its resistance to fault first practical fault attack against EdDSA or Ed25519. attacks is discussed in [10]–[12] and taken into account by Keywords-EdDSA; Ed25519; fault attack; digital signature Perrin in [13].
    [Show full text]
  • (Not) to Design and Implement Post-Quantum Cryptography
    SoK: How (not) to Design and Implement Post-Quantum Cryptography James Howe1 , Thomas Prest1 , and Daniel Apon2 1 PQShield, Oxford, UK. {james.howe,thomas.prest}@pqshield.com 2 National Institute of Standards and Technology, USA. [email protected] Abstract Post-quantum cryptography has known a Cambrian explo- sion in the last decade. What started as a very theoretical and mathe- matical area has now evolved into a sprawling research ˝eld, complete with side-channel resistant embedded implementations, large scale de- ployment tests and standardization e˙orts. This study systematizes the current state of knowledge on post-quantum cryptography. Compared to existing studies, we adopt a transversal point of view and center our study around three areas: (i) paradigms, (ii) implementation, (iii) deployment. Our point of view allows to cast almost all classical and post-quantum schemes into just a few paradigms. We highlight trends, common methodologies, and pitfalls to look for and recurrent challenges. 1 Introduction Since Shor's discovery of polynomial-time quantum algorithms for the factoring and discrete logarithm problems, researchers have looked at ways to manage the potential advent of large-scale quantum computers, a prospect which has become much more tangible of late. The proposed solutions are cryptographic schemes based on problems assumed to be resistant to quantum computers, such as those related to lattices or hash functions. Post-quantum cryptography (PQC) is an umbrella term that encompasses the design, implementation, and integration of these schemes. This document is a Systematization of Knowledge (SoK) on this diverse and progressive topic. We have made two editorial choices.
    [Show full text]
  • RFC 8998: Shangmi (SM) Cipher Suites for TLS
    Stream: Independent Submission RFC: 8998 Category: Informational Published: March 2021 ISSN: 2070-1721 Author: P. Yang Ant Group RFC 8998 ShangMi (SM) Cipher Suites for TLS 1.3 Abstract This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8998. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.
    [Show full text]
  • Introduction to the Commercial Cryptography Scheme in China
    Introduction to the Commercial Cryptography Scheme in China atsec China Di Li Yan Liu [email protected] [email protected] +86 138 1022 0119 +86 139 1072 6424 6 November 2015, Washington DC, U.S. © atsec information security, 2015 Disclaimer atsec China is an independent lab specializing in IT security evaluations. The authors do not represent any Chinese government agency or Chinese government-controlled lab. All information used for this presentation is publicly available on the Internet, despite the fact that most of them are in Chinese. 6 November 2015, Washington DC, U.S. 2 Agenda § Background on commercial cryptography in China § Product certification list § Published algorithms and standards § Certification scheme § Conclusions 6 November 2015, Washington DC, U.S. 3 What is “Commercial Cryptography”? 6 November 2015, Washington DC, U.S. 4 OSCCA and Commercial Cryptography − What is “Commercial Cryptography” in China? − “Commercial Cryptography” is a set of algorithms and standards used in the commercial area, e.g. banks, telecommunications, third party payment gateways, enterprises, etc. … − In this area, only “Commercial Cryptography” certified products can be used. − Constituted by the Chinese Academy of Science (CAS) − Issued and regulated by the Office of the State Commercial Cryptography Administration (OSCCA) − Established in 1999 − Testing lab setup in 2005 6 November 2015, Washington DC, U.S. 5 OSCCA Certified Product List Certified product list (1322 items): http://www.oscca.gov.cn/News/201510/News_1310.htm 6 November 2015, Washington DC, U.S. 6 Certified Products and Its Use − Security IC chip − Password keypad − Hardware token including Public Key Infrastructure (PKI), One Time Password (OTP), and its supporting system − Hardware security machine / card − Digital signature and verification system − IPSEC / SSL VPN Gateway − Value Added Tax (VAT) audit system 6 November 2015, Washington DC, U.S.
    [Show full text]
  • TCG Algorithm Registry Family "2.0"
    TCG Algorithm Registry Family “2.0" Level 00 Revision 01.22 February 9, 2015 Published Contact: [email protected] TCG Published TCG Copyright © TCG 2015 TCG Algorithm Registry Disclaimers, Notices, and License Terms THIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification and to the implementation of this specification, and TCG disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any way out of use or reliance upon this specification or any information herein. This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted herein other than as follows: You may not copy or reproduce the document or distribute it to others without written permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG specifications or (b) developing, testing, or promoting information technology standards and best practices, so long as you distribute the document with these disclaimers, notices, and license terms. Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing through membership agreements. Any marks and brands contained herein are the property of their respective owners.
    [Show full text]