DOCSLIB.ORG

SMPTE Standards Transition Issues for NIST/FIPS Requirements V1.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SMPTE Standards Transition Issues for NIST/FIPS Requirements V1.1 SMPTE Standards Transition Issues for NIST/FIPS Requirements v1.1 2010.8.23 DRM inside, Taehyun Kim ETRI, Kisoon Yoon Contents 1 Introduction NIST (National Institute of Standards and Technology) published second draft special document 1 (SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Length) [28] in June, 2010. It includes transition recommendations through 9 items associated with the use of cryptography, whose purpose is to keep the security level being still higher as the more powerful computing techniques are available. The 9 items described in the SP 800-131 are: • Encryption (Sec. 2) • Digital Signature (Sec. 3) • Random Number Generation (Sec. 4) • Key Agreement Using Diffie-Hellman and MQV (Sec. 5) • Key Agreement and Key Transport Using RSA (Sec. 6) • Key Wrapping (Sec. 7) • GDIO Protocol (Sec 8.) • Deriving Additional Keys (Sec. 8) • Hash Function (Sec. 9) • Message Authentication Codes (Sec. 10) Currently, SMPTE documents2 refer to the FIPS (Federal Information Processing Standard) to use its cryptographic algorithms which are Secure Hash Standard (FIPS 180-1, 180-2) [1][2], Digital Signature Standard (FIPS 186-2, Jan. 2000) [4], Random Number Generation (FIPS 186-2, Jan. 2000), Advanced Encryption Standard (FIPS 197, Nov. 2001) [6] and Keyed-Hash Message Authentication Code (FIPS 198-1, Apr. 2002) [7]. As upgrade version of the FIPSs and new recommendation are published from the NIST, we need to consider impacts on the SMPTE standard documents. This report summarizes SMPTE documents in cryptographic point of view and new NIST requirements related to the cryptographic algorithm and strength to which SMPTE standards are referring. And it also verifies if current algorithms and key length used in SMPTE standards are compliant to the new requirements. 2 SMPTE Standard List with Cryptography Specification SMPTE Chapter Cryptographic item Purpose Reference S427 5.1 LE_Key generation Random number generation Random number - [15] 6.3.1 Algorithm type RSA_oaep_mgf1p_sha1_2048 Key transport RFC 2437 [9] 1 It is a revised version reflecting public comments related on the delay of the imminent 2010 transition due date of the vulnerable algorithm or key length. The second draft temporarly grants delay of the deadline in some parts until 2013 or 2015 with the term ‘deprecated’. Currently NIST has received additional comments on the second version. 2 All SMPTE documents in this report are “SMPTE Standards for Digital Cinema” published or worked by SMPTE 21 DC. Other standard documents from other TC groups are not considered. 1 6.3.3 Hash SHA1 Integrity FIPS 180-1 [1] 6.4.5 LE Key Type AES-CTR-128 Data encryption FIPS 197 [6] 5.5 Cipher Algorithm AES-CBC-128 Data encryption FIPS 197 S429-6 5.6 MIC Algorithm HMAC-SHA1-128 Integrity RFC 2104 [8] [16] 6.10 MIC (Optional) MIC Key derivation Random number FIPS 186-2 [4] S429-7 Digest method : SHA-1 6.13 Signature (Optional) Digital signature FIPS 186-2 [17] Signature method : RSA-SHA256 8.2.2 Hash SHA-1 Integrity RFC3174 [11] S429-8 Digest method : SHA-1 5.10 Signature (Optional) Digital signature FIPS 186-2 [18] Signature method : RSA-SHA256 6.3 Hash SHA-1 Integrity RFC 3174 S430-1 None [19] (Refer 430-3) Signature algorithm:RSA-SHA256 Digital signature RFC 3280 [13] S430-2 5.2 Field Constraints Public Key : RSA-2048 Key algorithm RFC 3447 [14] [20] Hash for Public Key TP : SHA1 5.4 Thumbprint Key identifier FIPS 180-2 [2] Hash for Certificate Key TP : SHA1 6.1.1 Encryption method rsa-oaep-mgf1p Key agreement RFC 3447 6.1.2 KeyInfo D-Cinema certificate (RSA-2048) Key encryption RFC 3447 S430-3 6.2 EncryptedData AES-CBC-128 Data encryption FIPS 197 [21] Digest method : SHA-256 W3C XML- 7.2 SignatureInfo Digital signature Signature method : RSA-SHA256 Signature [29] 7.1.8 Previous Header Hash SHA-1 FIPS 180-1 7.1.9 Record Body Hash SHA-1 S430-4 7.3.3.1 Record Header Hash SHA-1 Digital signature [22] W3C XML- 7.3.4 Signature (Optional) xml-signature Signature S430-5 Digest method : SHA-256 W3C XML- 6.1.3 Log Record Signature Digital signature [23] Signature method : RSA-SHA256 Signature Communication channel : TLS Key transport RFC 2246 [9] S430-6 Public key algorithm : RSA-2048 Key encryption RFC 3447 6.1 Message Security [24] Cipher algorithm : AES-CBC-128 Data encryption RFC 3268 [12] HASH : SHA1 Integrity - S427: Link Encryption for 1.5Gb/s1 Serial Digital Interface S429-6: D-Cinema Packaging, MXF Track File Essence Encryption S429-7: D-Cinema Packaging, Composition Playlist S429-8: D-Cinema Packaging, Packing List S430-1: D-Cinema Operations Key Delivery Message S430-2: D-Cinema Operations Digital Certificate S430-3: D-Cinema Operations Generic Extra-Theatre Message Format S430-4: D-Cinema Operations, Log Record Format Specification S430-5: D-Cinema Operations, Security Log Event Class and Constraints S430-6: D-Cinema Operations, Auditorium Security Messages for Intra-Theater Communications FIPS 180-x: Secure Hash Standard FIPS 186-x: Digital Signature Standard FIPS 197: Advanced Encryption Standard FIPS 198-x: The Keyed-Hash Message Authentication Code RFC 2104: HMAC: Keyed-Hashing for Message Authentication RFC 2246: The TLS Protocol Version 1.0 RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0 RFC 3174: US Secure Hash Algorithm 1 RFC 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 3447:"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 SP 800-56B: Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography SP 800-57: Recommendation for Key Management SP 800-90: Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP 800-131: Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes 3 SMPTE Transition Issues on the SP 800-131 Recommendation 2 3.1 Encryption NIST recommends using Three-key Triple DES or above AES-128 encryption algorithm on new implementation after 2010. SMPTE currently uses only AES-128 algorithm for symmetric encryption (FIPS 197) in the S427, S429-6, S430-3 and S430-6. So there is NO transition issue on the symmetric encryption /decryption algorithm in the SMPTE standards. And under the current NIST recommendation, AES-128 is valid even beyond 2030. Therefore, there will be also no transition concern on this item for the time being. Algorithm Use (Encryption/Decryption) AES-128 Acceptable beyond 2010 AES-192 Acceptable beyond 2010 AES-256 Acceptable beyond 2010 Table 1 NIST Recommendation for Encryption [28] 3.2 Digital Signatures 3.2.1 Signature method NIST recommends using above 112 bits symmetric key length on new implementation of digital signature after 20103. SMPTE currently uses RSA algorithm with 2048 key size in the S429-7, S429-8, S430-2 and S430- 3. The asymmetric algorithm RSA with 2048 bits is regarded as having 112 bits symmetric key length [28]. So there is no transition issue on the Digital Signature (FIPS 186-x) in those SMPTE standards. However S430-5 (Section 6.1.3 Log record signature) specifies the algorithm to W3C’s xml-signature which allows DSS algorithm as well as RSA with any key length. Although S430-5’s xml-signature implicitly indicates using the digital cinema certificate which is required to have only RSA algorithm and 2048 key length [20], S430-5 needs to consider changing signature method as RSA instead of vague ‘xml-signature’ to keep consistency with other SMPTE standards at least before end of the 2013. And under the current NIST recommendation, RSA-2048 is valid until 2030. Therefore, if SMPTE wants to use this algorithm even beyond 2030, it needs to increase the key length to 3072 bits before 2030. Digital Signature Process Use 80 bits of security strength: Deprecated from 2011 through 2013 Signature RSA: 1024 ≤ |n| < 2048 Generation ≥ 112 bits of security strength: Acceptable beyond 2010 RSA: |n| ≥ 2048 80 bits of security strength: Legacy use after 2010 Signature RSA: 1024 ≤ |n| < 2048 Verification ≥ 112 bits of security strength: Acceptable beyond 2010 RSA: |n| ≥ 2048 Table 2 NIST Recommendation for Digital Signature Method [28] 3.2.2 Digest method NIST recommends using above SHA-224 on new implementation of digital signature after 2010 4. SMPTE currently uses both SHA1 (in S429-7, S429-8 and S430-4) and SHA256 (in S430-2 and S430-5) for the purpose of signature digest. The SHA1 of the SMPTE digest method may not be security critical issue because SMPTE uses it only at the optional signature part. However once someone used signature function, the algorithm is required to be secure enough. So it needs to consider changing SHA1 algorithms in the S429-7, S429-8 and S430-4 into SHA 256 according to FIPS 186-3 [4] at least before end of the 2013. Digital Signature Process Use 3 Transition can be delayed until 2013. But it is recommended to be done as soon as possible since it said the lower bits (e.g. above 80 bits) would be deprecated from 2011 to 2013. 4 Transition can be delayed until 2013. But it is recommended to be done as soon as possible since it said using of SHA-1 would be deprecated from 2011 to 2013. 3 Signature SHA-1 Deprecated from 2011 through 2013 Generation SHA-224, SHA-256, SHA-284, SHA-512 Acceptable beyond 2010 Signature SHA-1 Legacy use after 2010 Verification SHA-224, SHA-256, SHA-284, SHA-512 Acceptable beyond 2010 Table 3 NIST Recommendation for Digital Signature Digest Method [28] 3.3 Random Number Generation NIST recommends using the RNG method described in SP 800-90 [27] on new implementation of RNG after 20105.
Load more

Recommended publications
  • On the NIST Lightweight Cryptography Standardization
    On the NIST Lightweight Cryptography Standardization Meltem S¨onmez Turan NIST Lightweight Cryptography Team ECC 2019: 23rd Workshop on Elliptic Curve Cryptography December 2, 2019 Outline • NIST's Cryptography Standards • Overview - Lightweight Cryptography • NIST Lightweight Cryptography Standardization Process • Announcements 1 NIST's Cryptography Standards National Institute of Standards and Technology • Non-regulatory federal agency within U.S. Department of Commerce. • Founded in 1901, known as the National Bureau of Standards (NBS) prior to 1988. • Headquarters in Gaithersburg, Maryland, and laboratories in Boulder, Colorado. • Employs around 6,000 employees and associates. NIST's Mission to promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life. 2 NIST Organization Chart Laboratory Programs Computer Security Division • Center for Nanoscale Science and • Cryptographic Technology Technology • Secure Systems and Applications • Communications Technology Lab. • Security Outreach and Integration • Engineering Lab. • Security Components and Mechanisms • Information Technology Lab. • Security Test, Validation and • Material Measurement Lab. Measurements • NIST Center for Neutron Research • Physical Measurement Lab. Information Technology Lab. • Advanced Network Technologies • Applied and Computational Mathematics • Applied Cybersecurity • Computer Security • Information Access • Software and Systems • Statistical
    [Show full text]
  • TS 102 176-1 V2.1.1 (2011-07) Technical Specification
    ETSI TS 102 176-1 V2.1.1 (2011-07) Technical Specification Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms 2 ETSI TS 102 176-1 V2.1.1 (2011-07) Reference RTS/ESI-000080-1 Keywords e-commerce, electronic signature, security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission.
    [Show full text]
  • Guidelines on Cryptographic Algorithms Usage and Key Management
    EPC342-08 Version 7.0 4 November 2017 [X] Public – [ ] Internal Use – [ ] Confidential – [ ] Strictest Confidence Distribution: Publicly available GUIDELINES ON CRYPTOGRAPHIC ALGORITHMS USAGE AND KEY MANAGEMENT Abstract This document defines guidelines on cryptographic algorithms usage and key management. Document Reference EPC342-08 Issue Version 7.0 Date of Issue 22 November 2017 Reason for Issue Maintenance of document Produced by EPC Authorised by EPC Document History This document was first produced by ECBS as TR 406, with its latest ECBS version published in September 2005. The document has been handed over to the EPC which is responsible for its yearly maintenance. DISCLAIMER: Whilst the European Payments Council (EPC) has used its best endeavours to make sure that all the information, data, documentation (including references) and other material in the present document are accurate and complete, it does not accept liability for any errors or omissions. EPC will not be liable for any claims or losses of any nature arising directly or indirectly from use of the information, data, documentation or other material in the present document. Conseil Européen des Paiements AISBL– Cours Saint-Michel 30A – B 1040 Brussels Tel: +32 2 733 35 33 – Fax: +32 2 736 49 88 Enterprise N° 0873.268.927 – www.epc-cep.eu – [email protected] © 2016 Copyright European Payments Council (EPC) AISBL: Reproduction for non-commercial purposes is authorised, with acknowledgement of the source Table of Content MANAGEMENT SUMMARY ............................................................. 5 1 INTRODUCTION .................................................................... 7 1.1 Scope of the document ...................................................... 7 1.2 Document structure .......................................................... 7 1.3 Recommendations ............................................................ 8 1.4 Implementation best practices .........................................
    [Show full text]
  • BIP Note 18 Binding Implementation Practice (BIP) Note
    Superannuation Transaction Network BIP Note 18 Binding Implementation Practice (BIP) Note Title: TLS Configuration and Cryptography Date: 10 Nov 201 5 Standards Version: 1.0 Scope [ x ] transport layer Status: [ ] Draft [ ] message payload [x ] Ratified [ x ] security Live Date: 25 February 2016 On this date this BIP note will be binding on all participants 1. Change This document sets requirements for SSL/TLS configuration within the STN. 2. Reason for Change Secure message exchange within the STN is fully dependent on HTTPS protocol (HTTP over TLS). SSL 3.0 has existed for at least 15 years. It was superseded by TLS 1.0 which was in turn replaced by TLS 1.1 and TLS 1.2. Cryptography standards used in SSL and early versions of TLS are now deprecated and do not provide sufficient level of security. Clause 6.6(a) of Superannuation Data and Gateway Services Standards for Gateway Operators transaction within the Superannuation Transaction Network document requires STN gateways to use “a minimum level of protection of Transport Layer Security (TLS) of version 1.1 or above”. Majority of the STN gateways supports TLS versions 1.0 through 1.2 at the server side (some gateways still support SSL 3.0). However, only a few gateways support modern TLS versions at the client side resulting majority of transactions within the STN being sent through TLS 1.0 channel. In order to eliminate vulnerabilities of the obsolete SSL/TLS protocols, SSL 3.0 and TLS 1.0 must be completely disabled. Mozilla Foundation recommends not to include TLS 1.0 into “Modern” configuration set for web- servers and limits its usage only for backward-compatibility purposes (given that STN is P2P network with a limited number of participants, backward-compatibility issue is not relevant).
    [Show full text]
  • Cs 255 (Introduction to Cryptography)
    CS 255 (INTRODUCTION TO CRYPTOGRAPHY) DAVID WU Abstract. Notes taken in Professor Boneh’s Introduction to Cryptography course (CS 255) in Winter, 2012. There may be errors! Be warned! Contents 1. 1/11: Introduction and Stream Ciphers 2 1.1. Introduction 2 1.2. History of Cryptography 3 1.3. Stream Ciphers 4 1.4. Pseudorandom Generators (PRGs) 5 1.5. Attacks on Stream Ciphers and OTP 6 1.6. Stream Ciphers in Practice 6 2. 1/18: PRGs and Semantic Security 7 2.1. Secure PRGs 7 2.2. Semantic Security 8 2.3. Generating Random Bits in Practice 9 2.4. Block Ciphers 9 3. 1/23: Block Ciphers 9 3.1. Pseudorandom Functions (PRF) 9 3.2. Data Encryption Standard (DES) 10 3.3. Advanced Encryption Standard (AES) 12 3.4. Exhaustive Search Attacks 12 3.5. More Attacks on Block Ciphers 13 3.6. Block Cipher Modes of Operation 13 4. 1/25: Message Integrity 15 4.1. Message Integrity 15 5. 1/27: Proofs in Cryptography 17 5.1. Time/Space Tradeoff 17 5.2. Proofs in Cryptography 17 6. 1/30: MAC Functions 18 6.1. Message Integrity 18 6.2. MAC Padding 18 6.3. Parallel MAC (PMAC) 19 6.4. One-time MAC 20 6.5. Collision Resistance 21 7. 2/1: Collision Resistance 21 7.1. Collision Resistant Hash Functions 21 7.2. Construction of Collision Resistant Hash Functions 22 7.3. Provably Secure Compression Functions 23 8. 2/6: HMAC And Timing Attacks 23 8.1. HMAC 23 8.2.
    [Show full text]
  • Study on the Use of Cryptographic Techniques in Europe
    Study on the use of cryptographic techniques in Europe [Deliverable – 2011-12-19] Updated on 2012-04-20 II Study on the use of cryptographic techniques in Europe Contributors to this report Authors: Edward Hamilton and Mischa Kriens of Analysys Mason Ltd Rodica Tirtea of ENISA Supervisor of the project: Rodica Tirtea of ENISA ENISA staff involved in the project: Demosthenes Ikonomou, Stefan Schiffner Agreements or Acknowledgements ENISA would like to thank the contributors and reviewers of this study. Study on the use of cryptographic techniques in Europe III About ENISA The European Network and Information Security Agency (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU leg- islation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu. Contact details For contacting ENISA or for general enquiries on cryptography, please use the following de- tails: E-mail: [email protected] Internet: http://www.enisa.europa.eu Legal notice Notice must be taken that this publication represents the views and interpretations of the au- thors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA Regulation (EC) No 460/2004 as lastly amended by Regulation (EU) No 580/2011.
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • An Analysis of the Transport Layer Security Protocol
    An Analysis of the Transport Layer Security Protocol Thyla van der Merwe Thesis submitted to the University of London for the degree of Doctor of Philosophy Information Security Group School of Mathematics and Information Security Royal Holloway, University of London 2018 Declaration These doctoral studies were conducted under the supervision of Professor Kenneth G. Paterson. The work presented in this thesis is the result of original research I conducted, in collabo- ration with others, whilst enrolled in the School of Mathematics and Information Security as a candidate for the degree of Doctor of Philosophy. This work has not been submitted for any other degree or award in any other university or educational establishment. Thyla van der Merwe March, 2018 2 Dedication To my niece, Emma. May you always believe in your abilities, no matter what anybody tells you, and may you draw on the strength of our family for support, as I have done (especially your Gogo, she’s one tough lady). “If you’re going through hell, keep going.” Winston Churchill 3 Abstract The Transport Layer Security (TLS) protocol is the de facto means for securing commu- nications on the World Wide Web. Originally developed by Netscape Communications, the protocol came under the auspices of the Internet Engineering Task Force (IETF) in the mid 1990s and today serves millions, if not billions, of users on a daily basis. The ubiquitous nature of the protocol has, especially in recent years, made the protocol an attractive target for security researchers. Since the release of TLS 1.2 in 2008, the protocol has suffered many high-profile, and increasingly practical, attacks.
    [Show full text]
  • CRYPTREC Report 2001
    CRYPTREC 2001 CRYPTREC Report 2001 March 2002 Information-technology Promotion Agency, Japan Telecommunications Advancement Organization of Japan CRYPTREC 2001 Contents Introduction 1 On the CRYPTREC Evaluation Committee Report 3 Note on the use of this report 7 1 Overview of Cryptographic Technique Evaluation 8 1.1 Evaluation Organs and Schedule ･･････････････････････････････････････････8 1.2 How cryptography evaluation was carried out. ･･････････････････････････････12 1.3 Terminology ･････････････････････････････････････････････････････････13 1.4 Evaluation Committee Members ･････････････････････････････････････････14 2 Evaluation of public key cryptographic techniques 17 2.1 Target of Evaluation and Evaluation Method ････････････････････････････････17 2.1.1 Evaluated Cryptographic Techniques ･･･････････････････････････････････17 2.1.2 Evaluation Policy･･･････････････････････････････････････････････････17 2.1.3 Evaluation Method ･････････････････････････････････････････････････19 2.2 Evaluation result ･･････････････････････････････････････････････････････21 2.2.1 Outline of evaluation result ･･･････････････････････････････････････････21 2.2.2 General Evaluation of the Difficulty of Arithmetic Problems･････････････････23 2.2.3 Overall Judgment of Cryptographic Techniques that were the Target of Detailed Evaluation ･････････････････････････････････････････････････23 2.2.4 Overall Judgment of Cryptographic Techniques under Observation ･･･････････26 2.2.5 Overall Judgment of Cryptosystems that were Targets of Screening Evaluations in 2001
    [Show full text]
  • [PKCS#1] RSA Laboratories, PKCS #1 V2.1: RSA Cryptography Standard, June 14, 2002
    [PKCS#1] RSA Laboratories, PKCS #1 v2.1: RSA Cryptography Standard, June 14, 2002, http://www.preserveitall.org/emc-plus/rsa-labs/standards-initiatives/pkcs-rsa- cryptography-standard.htm. [PKCS#5] RSA Laboratories, PKCS #5 v2.1: Password-Based Cryptography Standard, October 5, 2006, http://www.preserveitall.org/emc-plus/rsa-labs/standards- initiatives/pkcs-5-password-based-cryptography-standard.htm. [PKCS#8] RSA Laboratories, PKCS#8 v1.2: Private-Key Information Syntax Standard, November 1, 1993, http://www.preserveitall.org/emc-plus/rsa-labs/standards- initiatives/pkcs-8-private-key-information-syntax-stand.htm. [PKCS#10] RSA Laboratories, PKCS #10 v1.7: Certification Request Syntax Standard, May 26, 2000, http://www.preserveitall.org/emc-plus/rsa-labs/standards- initiatives/pkcs10-certification-request-syntax-standard.htm. [PKCS#11] OASIS PKCS #11 Cryptographic Token Interface Base Specification Version 3.0 [POLY1305] Daniel J. Bernstein. The Poly1305-AES Message-Authentication Code. In Henri Gilbert and Helena Handschuh, editors, Fast Software Encryption: 12th International Workshop, FSE 2005, Paris, France, February 21-23, 2005, Revised Selected Papers, volume 3557 of Lecture Notes in Computer Science, pages 32–49. Springer, 2005. [RFC1319] B. Kaliski, The MD2 Message-Digest Algorithm, IETF RFC 1319, Apr 1992, http://www.ietf.org/rfc/rfc1319.txt. [RFC1320] R. Rivest, The MD4 Message-Digest Algorithm, IETF RFC 1320, April 1992, http://www.ietf.org/rfc/rfc1320.txt. [RFC1321] R. Rivest, The MD5 Message-Digest Algorithm, IETF RFC 1321, April 1992, http://www.ietf.org/rfc/rfc1321.txt. [RFC1421] J. Linn, Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures, IETF RFC 1421, February 1993, http://www.ietf.org/rfc/rfc1421.txt.
    [Show full text]
  • Configuring Ipsec Virtual Private Networks
    National Security Agency | Cybersecurity Information Configuring IPsec Virtual Private Networks The recent NSA publication “Securing IPsec Virtual Private Networks” [1] lays out the importance of IP Security (IPsec) Virtual Private Networks (VPNs) and outlines specific recommendations for securing those connections. It is critical that VPNs use strong cryptography. This guidance goes deeper, providing device administrators with specific instructions.1 Maintaining a secure VPN tunnel can be complex and requires regular maintenance. To maintain a secure VPN, network administrators should perform the following tasks on a regular basis: Reduce the VPN gateway attack surface Verify that cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant Avoid using default VPN settings Remove unused or non-compliant cryptography suites Apply vendor-provided updates (i.e. patches) for VPN gateways and clients Reduce the VPN gateway attack surface VPN gateways tend to be directly accessible from the Internet and are prone to network scanning, brute force attacks, and zero day vulnerabilities. To mitigate many of these vulnerabilities, network administrators should implement strict traffic filtering rules: Limiting access to UDP port 500, UDP port 4500, and ESP. When possible, limit accepted traffic to known VPN peer IP addresses. Remote access VPNs present the issue of the remote peer IP address being unknown and therefore it cannot be added to a static filtering rule. If traffic cannot be filtered to a specific IP address, NSA recommends an Intrusion Prevent System (IPS) in front of the VPN gateway to monitor for malformed IPsec traffic and inspect IPsec session negotiations. Examples of recommended ACLs and IPS signatures for anomalous ISAKMP/IKE traffic can be found in Appendices A and D.
    [Show full text]
  • Etsi Ts 119 312 V1.2.1 (2017-05)
    ETSI TS 119 312 V1.2.1 (2017-05) TECHNICAL SPECIFICATION Electronic Signatures and Infrastructures (ESI); Cryptographic Suites 2 ETSI TS 119 312 V1.2.1 (2017-05) Reference RTS/ESI-0019312v121 Keywords e-commerce, electronic signature, security, trust services ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]