PSA Cryptography API 1.0

Total Page:16

File Type:pdf, Size:1020Kb

PSA Cryptography API 1.0 PSA Cryptography API 1.0 Document number: IHI 0086 Release Quality: Final Issue Number: 1 Confidentiality: Non-confidential Date of Issue: 27/08/2020 Copyright © 2018-2020, Arm Limited. All rights reserved. Contents About this document vii Release information vii Arm Non-Confidential Document Licence (“Licence”) viii References x Terms and abbreviations xiii Potential for change xv Conventions xv Typographical conventions xv Numbers xv Pseudocode descriptions xvi Assembler syntax descriptions xvi Feedback xvi Feedback on this book xvi 1 Introduction 17 2 Design goals 17 2.1 Suitable for constrained devices 17 2.2 A keystore interface 18 2.3 Optional isolation 18 2.4 Choice of algorithms 19 2.5 Ease of use 19 2.6 Example use cases 19 2.6.1 Network Security (TLS) 19 2.6.2 Secure Storage 19 2.6.3 Network Credentials 20 2.6.4 Device Pairing 20 2.6.5 Secure Boot 20 2.6.6 Attestation 20 2.6.7 Factory Provisioning 20 3 Functionality overview 20 3.1 Library management 20 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page i 1.0.1 Non-confidential 3.2 Key management 21 3.2.1 Key identifiers 21 3.2.2 Key lifetimes 22 3.2.3 Key policies 22 3.2.4 Recommendations of minimum standards for key management 22 3.3 Symmetric cryptography 22 3.3.1 Single-part Functions 23 3.3.2 Multi-part operations 23 3.3.3 Message digests (Hashes) 24 3.3.4 Message authentication codes (MACs) 25 3.3.5 Encryption and decryption 25 3.3.6 Authenticated encryption (AEAD) 26 3.3.7 Key derivation 27 3.3.8 Example of the symmetric cryptography API 28 3.4 Asymmetric cryptography 28 3.4.1 Asymmetric encryption 29 3.4.2 Hash-and-sign 29 3.4.3 Key agreement 29 3.5 Randomness and key generation 29 4 Sample architectures 29 4.1 Single-partition architecture 30 4.2 Cryptographic token and single-application processor 30 4.3 Cryptoprocessor with no key storage 30 4.4 Multi-client cryptoprocessor 31 4.5 Multi-cryptoprocessor architecture 31 5 Library conventions 31 5.1 Error handling 31 5.1.1 Return status 31 5.1.2 Behavior on error 32 5.2 Parameter conventions 33 5.2.1 Pointer conventions 33 5.2.2 Input buffer sizes 33 5.2.3 Output buffer sizes 33 5.2.4 Overlap between parameters 34 5.2.5 Stability of parameters 34 5.3 Key types and algorithms 35 5.3.1 Structure of key and algorithm types 35 5.4 Concurrent calls 35 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page ii 1.0.1 Non-confidential 6 Implementation considerations 36 6.1 Implementation-specific aspects of the interface 36 6.1.1 Implementation profile 36 6.1.2 Implementation-specific types 36 6.1.3 Implementation-specific macros 36 6.2 Porting to a platform 37 6.2.1 Platform assumptions 37 6.2.2 Platform-specific types 37 6.2.3 Cryptographic hardware support 38 6.3 Security requirements and recommendations 38 6.3.1 Error detection 38 6.3.2 Indirect object references 38 6.3.3 Memory cleanup 38 6.3.4 Managing key material 39 6.3.5 Safe outputs on error 39 6.3.6 Attack resistance 40 6.4 Other implementation considerations 40 6.4.1 Philosophy of resource management 40 7 Usage considerations 40 7.1 Security recommendations 40 7.1.1 Always check for errors 40 7.1.2 Shared memory and concurrency 41 7.1.3 Cleaning up after use 41 8 Library management reference 41 8.1 PSA status codes 41 8.1.1 Status type 41 8.1.2 Success codes 42 8.1.3 Error codes 42 8.2 PSA Crypto library 48 8.2.1 API version 48 8.2.2 Library initialization 48 9 Key management reference 49 9.1 Key attributes 49 9.1.1 Managing key attributes 49 9.2 Key types 53 9.2.1 Key type encoding 53 9.2.2 Key categories 54 9.2.3 Symmetric keys 55 9.2.4 RSA keys 58 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page iii 1.0.1 Non-confidential 9.2.5 Elliptic Curve keys 58 9.2.6 Diffie Hellman keys 63 9.2.7 Attribute accessors 65 9.3 Key lifetimes 68 9.3.1 Volatile keys 68 9.3.2 Persistent keys 68 9.3.3 Lifetime encodings 69 9.3.4 Lifetime values 72 9.3.5 Attribute accessors 73 9.3.6 Support macros 74 9.4 Key identifiers 75 9.4.1 Key identifier type 76 9.4.2 Attribute accessors 77 9.5 Key policies 78 9.5.1 Permitted algorithms 78 9.5.2 Key usage flags 80 9.6 Key management functions 84 9.6.1 Key creation 84 9.6.2 Key destruction 90 9.6.3 Key export 92 10 Cryptographic operation reference 98 10.1 Algorithms 98 10.1.1 Algorithm encoding 99 10.1.2 Algorithm categories 100 10.2 Message digests 103 10.2.1 Hash algorithms 103 10.2.2 Single-part hashing functions 106 10.2.3 Multi-part hashing operations 108 10.2.4 Support macros 117 10.2.5 Hash suspend state 120 10.3 Message authentication codes (MAC) 122 10.3.1 MAC algorithms 122 10.3.2 Single-part MAC functions 123 10.3.3 Multi-part MAC operations 126 10.3.4 Support macros 133 10.4 Unauthenticated ciphers 135 10.4.1 Cipher algorithms 135 10.4.2 Single-part cipher functions 139 10.4.3 Multi-part cipher operations 142 10.4.4 Support macros 151 10.5 Authenticated encryption with associated data (AEAD) 157 10.5.1 AEAD algorithms 157 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page iv 1.0.1 Non-confidential 10.5.2 Single-part AEAD functions 158 10.5.3 Multi-part AEAD operations 162 10.5.4 Support macros 176 10.6 Key derivation 181 10.6.1 Key derivation algorithms 181 10.6.2 Input step types 184 10.6.3 Key derivation functions 185 10.6.4 Support macros 196 10.7 Asymmetric signature 198 10.7.1 Asymmetric signature algorithms 198 10.7.2 Asymmetric signature functions 201 10.7.3 Support macros 207 10.8 Asymmetric encryption 211 10.8.1 Asymmetric encryption algorithms 211 10.8.2 Asymmetric encryption functions 212 10.8.3 Support macros 215 10.9 Key agreement 217 10.9.1 Key agreement algorithms 217 10.9.2 Standalone key agreement 218 10.9.3 Combining key agreement and key derivation 220 10.9.4 Support macros 221 10.10 Other cryptographic services 224 10.10.1 Random number generation 224 A Example header file 226 A.1 psa/crypto.h 226 B Example macro implementations 237 B.1 Algorithm macros 237 B.2 Key type macros 240 B.3 Hash suspend state macros 241 C Changes to the API 242 C.1 Document change history 242 C.1.1 Changes between 1.0.0 and 1.0.1 242 C.1.2 Changes between 1.0 beta 3 and 1.0.0 243 C.1.3 Changes between 1.0 beta 2 and 1.0 beta 3 253 C.1.4 Changes between 1.0 beta 1 and 1.0 beta 2 254 C.2 Planned changes for version 1.0.x 254 C.3 Future additions 254 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page v 1.0.1 Non-confidential Index of API elements 256 IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page vi 1.0.1 Non-confidential About this document Release information The change history table lists the changes that have been made to this document. Date Version Confidentiality Change January 2019 1.0 Beta 1 Non-confidential First public beta release. February 2019 1.0 Beta 2 Non-confidential Update for release with other PSA Dev API specifications. May 2019 1.0 Beta 3 Non-confidential Update for release with other PSA API specifications. February 2020 1.0 Final Non-confidential 1.0 API finalized. August 2020 1.0.1 Final Non-confidential Update to fix errors and provide clarifications. The detailed changes in each release are described in Document change history on page 242. IHI 0086 Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. Page vii 1.0.1 Non-confidential PSA Cryptography API Copyright © 2018-2020, Arm Limited or its affiliates. All rights reserved. The copyright statement reflects the fact that some draft issues of this document have been released, to a limited circulation. Arm Non-Confidential Document Licence (“Licence”) This Licence is a legal agreement between you and Arm Limited (“Arm”) for the use of Arm’s intellectual property (including, without limitation, any copyright) embodied in the document accompanying this Licence (“Document”). Arm licenses its intellectual property in the Document to you on condition that you agree to the terms of this Licence. By using or copying the Document you indicate that you agree to be bound by the terms of this Licence. “Subsidiary” means any company the majority of whose voting shares is now or hereafter owner or controlled, directly or indirectly, by you. A company shall be a Subsidiary only for the period during which such control exists.
Recommended publications
  • Environmental DNA Reveals the Fine-Grained and Hierarchical
    www.nature.com/scientificreports OPEN Environmental DNA reveals the fne‑grained and hierarchical spatial structure of kelp forest fsh communities Thomas Lamy 1,2*, Kathleen J. Pitz 3, Francisco P. Chavez3, Christie E. Yorke1 & Robert J. Miller1 Biodiversity is changing at an accelerating rate at both local and regional scales. Beta diversity, which quantifes species turnover between these two scales, is emerging as a key driver of ecosystem function that can inform spatial conservation. Yet measuring biodiversity remains a major challenge, especially in aquatic ecosystems. Decoding environmental DNA (eDNA) left behind by organisms ofers the possibility of detecting species sans direct observation, a Rosetta Stone for biodiversity. While eDNA has proven useful to illuminate diversity in aquatic ecosystems, its utility for measuring beta diversity over spatial scales small enough to be relevant to conservation purposes is poorly known. Here we tested how eDNA performs relative to underwater visual census (UVC) to evaluate beta diversity of marine communities. We paired UVC with 12S eDNA metabarcoding and used a spatially structured hierarchical sampling design to assess key spatial metrics of fsh communities on temperate rocky reefs in southern California. eDNA provided a more‑detailed picture of the main sources of spatial variation in both taxonomic richness and community turnover, which primarily arose due to strong species fltering within and among rocky reefs. As expected, eDNA detected more taxa at the regional scale (69 vs. 38) which accumulated quickly with space and plateaued at only ~ 11 samples. Conversely, the discovery rate of new taxa was slower with no sign of saturation for UVC.
    [Show full text]
  • 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]
  • 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]
  • A Framework for Fully-Simulatable H-Out-Of-N Oblivious Transfer
    1 A Framework For Fully-Simulatable h-Out-Of-n Oblivious Transfer Zeng Bing, Tang Xueming, and Chingfang Hsu ✦ Abstract—We present a framework for fully-simulatable h-out-of-n where i1 < i2 <...<ih 6 n. The receiver expects to oblivious transfer (OT n) with security against non-adaptive malicious h get the messages mi1 ,mi2 ,...,mih without leaking any adversaries. The framework costs six communication rounds and costs information about his private input, i.e., the h positive at most 40n public-key operations in computational overhead. Com- integers he holds. The sender expects all new knowledge pared with the known protocols for fully-simulatable oblivious transfer that works in the plain mode (where there is no trusted common learned by the receiver from their interaction is at most reference string available) and proven to be secure under standard h messages. Obviously, the OT most literature refer to is 2 n model (where there is no random oracle available), the instantiation OT1 and can be viewed as a special case of OTh . based on the decisional Diffie-Hellman assumption of the framework is Considering a variety of attack we have to confront the most efficient one, no matter seen from communication rounds or n in real environment, a protocol for OTh with security computational overhead. against malicious adversaries (a malicious adversary Our framework uses three abstract tools, i.e., perfectly binding com- mitment, perfectly hiding commitment and our new smooth projective may act in any arbitrary malicious way to learn as much hash. This allows a simple and intuitive understanding of its security.
    [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]
  • Trusted Platform Module Library Part 1: Architecture TCG Public Review
    Trusted Platform Module Library Part 1: Architecture Family “2.0” Level 00 Revision 01.50 September 18, 2018 Committee Draft Contact: [email protected] Work in Progress This document is an intermediate draft for comment only and is subject to change without notice. Readers should not design products based on this document. TCG Public Review Copyright © TCG 2006-2019 TCG Trusted Platform Module Library Part 1: Architecture Licenses and Notices Copyright Licenses: Trusted Computing Group (TCG) grants to the user of the source code in this specification (the “Source Code”) a worldwide, irrevocable, nonexclusive, royalty free, copyright license to reproduce, create derivative works, distribute, display and perform the Source Code and derivative works thereof, and to grant others the rights granted herein. The TCG grants to the user of the other parts of the specification (other than the Source Code) the rights to reproduce, distribute, display, and perform the specification solely for the purpose of developing products based on such documents. Source Code Distribution Conditions: Redistributions of Source Code must retain the above copyright licenses, this list of conditions and the following disclaimers. Redistributions in binary form must reproduce the above copyright licenses, this list of conditions and the following disclaimers in the documentation and/or other materials provided with the distribution. Disclaimers: THE COPYRIGHT LICENSES SET FORTH ABOVE DO NOT REPRESENT ANY FORM OF LICENSE OR WAIVER, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, WITH RESPECT TO PATENT RIGHTS HELD BY TCG MEMBERS (OR OTHER THIRD PARTIES) THAT MAY BE NECESSARY TO IMPLEMENT THIS SPECIFICATION OR OTHERWISE. Contact TCG Administration ([email protected]) for information on specification licensing rights available through TCG membership agreements.
    [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]
  • S-Box Optimization for SM4 Algorithm
    Proceedings of the World Congress on Engineering and Computer Science 2017 Vol I WCECS 2017, October 25-27, 2017, San Francisco, USA S-box Optimization for SM4 Algorithm Yuan Zhu, Fang Zhou, Ning Wu, Yasir derivation process. In [4]-[5], S-boxes based on polynomial Abstract—This paper proposes a highly optimized S-box of basis and normal basis were introduced. Their optimizations SM4 algorithm for low-area and high-speed embedded for S-box focused on the hardware overhead at the cost of application. A novel methodology is adopted for S-box throughput. Therefore, when the SM4 algorithm is used for implementation based on Composite Field Arithmetic (CFA) and mixed basis. The optimization result shows that the S-box high-throughput and area-constrained devices, a short-delay based on mixed basis has shorter critical path than S-boxes and compact S-box is required for SM4 hardware based on normal basis and polynomial basis. Compared with implementation. previous works, the mixed basis based S-box proposed in this This study focuses on the optimization of S-box for SM4 paper can achieve the shortest critical path. Besides, the and the major contributions include: 2 2 operations over GF((2 ) ) and the constant matrix Coalescence design and implementation based on CFA multiplications are optimized by Delay-Aware Common Sub-expression Elimination (DACSE) algorithm. ASIC technology [6] and mixed basis [7]. 2 2 implementation using static 180 nm @ 1.8 V yield an area The MI over GF((2) ) and constant matrix reduction of 35.57% as compared to direct implementation.
    [Show full text]
  • Unbalanced Sharing: a Threshold Implementation of SM4
    SCIENCE CHINA Information Sciences May 2021, Vol. 64 159102:1–159102:3 . LETTER . https://doi.org/10.1007/s11432-018-9794-6 Unbalanced sharing: a threshold implementation of SM4 Man WEI1,2,3, Siwei SUN1,2,3*, Zihao WEI1,2,3 & Lei HU1,2,3 1State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences, Beijing 100093, China; 2Data Assurance and Communication Security Research Center, Chinese Academy of Sciences, Beijing 100093, China; 3 School of Cyber Security, University of Chinese Academy of Sciences, Beijing 100049, China Received 3 November 2018/Accepted 20 February 2019/Published online 19 March 2021 Citation Wei M, Sun S W, Wei Z H, et al. Unbalanced sharing: a threshold implementation of SM4. Sci China Inf Sci, 2021, 64(5): 159102, https://doi.org/10.1007/s11432-018-9794-6 Dear editor, ent input variables are split into different numbers of shares In recent years, we have witnessed a rapid development still maintains the three essential properties for TIs. Such of the side-channel attacks, which deviate from the tradi- a scheme is named an unbalanced sharing scheme. Taking the multiplication function y = f(x1,x2) = x1x2 as an ex- tional block-box model and exploit the leakages of crypto- 1 1 1 1 2 ample, we split x into 3 shares (x1,x2,x3), and x into 5 graphic devices. Among those attacks, the so-called differen- 2 2 2 2 2 tial power analysis (DPA) exploiting the correlation between shares (x1,x2,x3,x4,x5), and the sharing is given by the instantaneous power consumption and the sensitive in- 1 1 2 2 2 2 2 2 y1 = x2 + x3x2 + x3 + x4 + x5 + x4 + x5, termediate values of a cryptographic algorithm is one of the 1 2 2 2 2 1 2 2 most powerful techniques [1].
    [Show full text]
  • Iso/Iec 18033-3:2010 Dam 2
    DRAFT AMENDMENT ISO/IEC 18033-3:2010 DAM 2 ISO/IEC JTC 1/SC 27 Secretariat: DIN Voting begins on: Voting terminates on: 2018-07-19 2018-10-11 Information technology — Security techniques — Encryption algorithms — Part 3: Block ciphers AMENDMENT 2: SM4 Technologies de l'information — Techniques de sécurité — Algorithmes de chiffrement — Partie 3: Chiffrement par blocs AMENDEMENT 2: . iTeh STANDARD PREVIEW ICS: 35.030 (standards.iteh.ai) ISO/IEC 18033-3:2010/DAmd 2 https://standards.iteh.ai/catalog/standards/sist/b9d423fe-1fde-4195-82d8- a232c08c09b0/iso-iec-18033-3-2010-damd-2 THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH. IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, This document is circulated as received from the committee secretariat. TECHNOLOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME STANDARDS TO WHICH REFERENCE MAY BE MADE IN Reference number NATIONAL REGULATIONS. ISO/IEC 18033-3:2010/DAM 2:2018(E) RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT, WITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE AND TO PROVIDE SUPPORTING DOCUMENTATION. © ISO/IEC 2018 ISO/IEC 18033-3:2010/DAM 2:2018(E) iTeh STANDARD PREVIEW (standards.iteh.ai) ISO/IEC 18033-3:2010/DAmd 2 https://standards.iteh.ai/catalog/standards/sist/b9d423fe-1fde-4195-82d8- a232c08c09b0/iso-iec-18033-3-2010-damd-2 COPYRIGHT PROTECTED DOCUMENT © ISO/IEC 2018 All rights reserved.
    [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 18 May 2016 © atsec information security, 2016 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. 18 May 2016, Ottawa, Ontario, Canada 2 Agenda ▪ Background on commercial cryptography in China ▪ Product certification list ▪ Published algorithms and standards ▪ Certification scheme ▪ Conclusions 18 May 2016, Ottawa, Ontario, Canada 3 What is “Commercial Cryptography”? 18 May 2016, Ottawa, Ontario, Canada 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 18 May 2016, Ottawa, Ontario, Canada 5 OSCCA Certified Product List Certified product list (1509 items): Until 2016-02-29 http://www.oscca.gov.cn/News/201603/News_1321. htm Sequence Product Product
    [Show full text]