DOCSLIB.ORG

FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 NSS

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 NSS FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 NSS Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-4.0.0 Date: January 22nd, 2020 Document Version 2.3 © Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux 7 NSS Cryptographic Module Security Policy Date: January 22nd, 2020 Author: Oracle Security Evaluations – Global Product Security Contributing Authors: Oracle Linux Engineering Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 7 NSS Cryptographic Module Security Policy i TABLE OF CONTENTS Section Title Page 1. Introduction ......................................................................................................................................................................... 1 1.1 Overview ................................................................................................................................................................................ 1 1.2 Document Organization ......................................................................................................................................................... 1 2. Oracle Linux 7 NSS Cryptographic Module ........................................................................................................................... 2 2.1 Functional Overview .............................................................................................................................................................. 2 2.2 FIPS 140-2 Validation Scope ................................................................................................................................................... 2 3. Cryptographic Module Specification .................................................................................................................................... 3 3.1 Definition of the Cryptographic Module ................................................................................................................................ 3 3.2 Definition of the Physical Cryptographic Boundary ............................................................................................................... 4 3.3 Approved or Allowed Security Functions ............................................................................................................................... 4 3.4 Non-Approved but Allowed Security Functions ..................................................................................................................... 6 3.5 Non-Approved Security Functions ......................................................................................................................................... 6 4. Module Ports and Interfaces ................................................................................................................................................ 8 4.1 PKCS#11 ................................................................................................................................................................................. 8 4.2 Inhibition of Data Output ....................................................................................................................................................... 8 4.3 Disconnecting the Output Data Path from the Key Processes ............................................................................................... 9 5. Physical Security .................................................................................................................................................................10 6. Operational Environment....................................................................................................................................................11 6.1 Tested Environments ........................................................................................................................................................... 11 6.2 Vendor Affirmed Environments ........................................................................................................................................... 11 6.3 Operational Environment Policy .......................................................................................................................................... 15 7. Roles, Services and Authentication .....................................................................................................................................16 7.1 Roles ..................................................................................................................................................................................... 16 7.2 FIPS Approved Operator Services and Descriptions ............................................................................................................ 16 7.3 Non-FIPS Approved Services and Descriptions .................................................................................................................... 21 7.4 Operator Authentication ...................................................................................................................................................... 22 7.4.1 Role Assumption .................................................................................................................................................................. 22 7.4.2 Strength of Authentication Mechanism ............................................................................................................................... 23 8. Key and CSP Management ..................................................................................................................................................24 8.1 Random Number Generation ............................................................................................................................................... 25 8.2 Key/CSP Storage ................................................................................................................................................................... 25 8.3 Key/CSP Zeroization ............................................................................................................................................................. 25 9. Self-Tests ............................................................................................................................................................................26 9.1 Power-Up Self-Tests ............................................................................................................................................................. 26 9.2 Conditional Self-Tests .......................................................................................................................................................... 26 10. Crypto-Officer and User Guidance .......................................................................................................................................27 10.1 Crypto-Officer Guidance ...................................................................................................................................................... 27 10.1.1 Access to Audit Data ............................................................................................................................................................ 29 10.2 User Guidance ...................................................................................................................................................................... 29 10.2.1 TLS Operations ..................................................................................................................................................................... 30 10.2.2 RSA and DSA Keys ................................................................................................................................................................ 30 10.2.3 Triple-DES keys ..................................................................................................................................................................... 31 10.3 Handling Self-Test Errors ...................................................................................................................................................... 31 Oracle Linux 7 NSS Cryptographic Module Security Policy ii 11. Mitigation of Other Attacks ................................................................................................................................................32 Acronyms, Terms and Abbreviations .........................................................................................................................................33
Load more

Recommended publications
  • Advanced Encryption Standard Real-World Alternatives
    Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives CPSC 367: Cryptography and Security Michael Fischer Lecture 7 February 5, 2019 Thanks to Ewa Syta for the slides on AES CPSC 367, Lecture 7 1/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Multiple Encryption Composition Group property Birthday Attack Advanced Encryption Standard AES Real-World Issues Alternative Private Key Block Ciphers CPSC 367, Lecture 7 2/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Multiple Encryption CPSC 367, Lecture 7 3/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Composition of cryptosystems Encrypting a message multiple times with the same or different ciphers and keys seems to make the cipher stronger, but that's not always the case. The security of the composition can be difficult to analyze. For example, with the one-time pad, the encryption and decryption functions Ek and Dk are the same. The composition Ek ◦ Ek is the identity function! CPSC 367, Lecture 7 4/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Composition within practical cryptosystems Practical symmetric cryptosystems such as DES and AES are built as a composition of simpler systems. Each component offers little security by itself, but when composed, the layers obscure the message to the point that it is difficult for an adversary to recover. The trick is to find ciphers that successfully hide useful information from a would-be attacker when used in concert. CPSC 367, Lecture 7 5/58 Outline Multiple Encryption Birthday Attack Advanced Encryption Standard Real-World Alternatives Composition Double Encryption Double encryption is when a cryptosystem is composed with itself.
    [Show full text]
  • Implementations of Block Cipher SEED on Smartphone Operating Systems
    SECURWARE 2011 : The Fifth International Conference on Emerging Security Information, Systems and Technologies Implementations of Block Cipher SEED on Smartphone Operating Systems HwanJin Lee, DongHoon Shin, and Hyun-Chul Jung Security R&D Team Korea Internet & Security Agency (KISA) Seoul, Korea {lhj79, dhshin, hcjung}@kisa.or.kr Abstract—As more and more people are using smartphones limited power and offers inferior performance compared to a these days, a great deal of important information, such as PC. Therefore, it is difficult to use an open cryptographic personal information and the important documents of library such as OpenSSL, which is designed for the PC corporations among other things, are being saved on environment, in a smartphone. We need to study on the way smartphones. Unlike a PC, people can access another person’s for the effective use of SEED in smartphone. smartphone without great difficulty, and there is a high This paper presents the results of implementing the block possibility of losing one’s smartphone. If smartphone is lost cipher SEED to a smartphone. The results of a comparison without encryption, important information can be exploited. In with open cryptographic libraries (OpenSSL, BouncyCastle) addition, the open cryptographic library for PCs cannot be will also be presented. The SEED is a block cipher used due to the limited performance of the smartphone. This established as an international standard ISO/IEC and the paper introduces the optimization implementation technique for the smartphone OS and the results of using that technique. Korean standard. Section 2 introduces the SEED and open In addition, the results of a speed comparison with the open cryptographic libraries; Section 3 introduces smartphone cryptographic library will be presented.
    [Show full text]
  • Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and Performance-Friendly ∗
    Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and Performance-Friendly ∗ Brian Rogers, Siddhartha Chhabra, Yan Solihin Milos Prvulovic Dept. of Electrical and Computer Engineering College of Computing North Carolina State University Georgia Institute of Technology {bmrogers, schhabr, solihin}@ncsu.edu [email protected] Abstract and feasible threat is physical or hardware attacks which involve placing a bus analyzer that snoops data communicated between the In today’s digital world, computer security issues have become processor chip and other chips [7, 8]. Although physical attacks increasingly important. In particular, researchers have proposed may be more difficult to perform than software-based attacks, they designs for secure processors which utilize hardware-based mem- are very powerful as they can bypass any software security protec- ory encryption and integrity verification to protect the privacy and tion employed in the system. The proliferation of mod-chips that integrity of computation even from sophisticated physical attacks. bypass Digital Rights Management protection in game systems has However, currently proposed schemes remain hampered by prob- demonstrated that given sufficient financial payoffs, physical attacks lems that make them impractical for use in today’s computer sys- are very realistic threats. tems: lack of virtual memory and Inter-Process Communication Recognizing these threats, computer architecture researchers support as well as excessive storage and performance overheads. have recently proposed various types of secure processor architec- In this paper, we propose 1) Address Independent Seed Encryption tures [4, 5, 13, 14, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26]. Secure pro- (AISE), a counter-mode based memory encryption scheme using a cessors assume that off-chip communication is vulnerable to attack novel seed composition, and 2) Bonsai Merkle Trees (BMT), a novel and that the chip boundary provides a natural security boundary.
    [Show full text]
  • Extending NIST's CAVP Testing of Cryptographic Hash Function
    Extending NIST’s CAVP Testing of Cryptographic Hash Function Implementations Nicky Mouha and Christopher Celi National Institute of Standards and Technology, Gaithersburg, MD, USA [email protected],[email protected] Abstract. This paper describes a vulnerability in Apple’s CoreCrypto library, which affects 11 out of the 12 implemented hash functions: every implemented hash function except MD2 (Message Digest 2), as well as several higher-level operations such as the Hash-based Message Authen- tication Code (HMAC) and the Ed25519 signature scheme. The vulnera- bility is present in each of Apple’s CoreCrypto libraries that are currently validated under FIPS 140-2 (Federal Information Processing Standard). For inputs of about 232 bytes (4 GiB) or more, the implementations do not produce the correct output, but instead enter into an infinite loop. The vulnerability shows a limitation in the Cryptographic Algorithm Validation Program (CAVP) of the National Institute of Standards and Technology (NIST), which currently does not perform tests on hash func- tions for inputs larger than 65 535 bits. To overcome this limitation of NIST’s CAVP, we introduce a new test type called the Large Data Test (LDT). The LDT detects vulnerabilities similar to that in CoreCrypto in implementations submitted for validation under FIPS 140-2. Keywords: CVE-2019-8741, FIPS, CAVP, ACVP, Apple, CoreCrypto, hash function, vulnerability. 1 Introduction The security of cryptography in practice relies not only on the resistance of the algorithms against cryptanalytical attacks, but also on the correctness and robustness of their implementations. Software implementations are vulnerable to software faults, also known as bugs.
    [Show full text]
  • Preliminary Analysis: SEED’S First Year
    SEED Findings Summary stocktondemonstration.org Preliminary Analysis: SEED’s First Year AUTHORS: CONTRIBUTING RESEARCHERS: Dr. Stacia West, Mina Addo, Mae Carlson, Dr. Amy Castro Baker, Conway Homes Residents Council, Sukhi Samra, Pandora Crowder, Meagan Cusack, Stacy Elliott, Erin Coltrera Daniel Horn, Jenna Steckel, Tooma Zaghloul Preliminary Analysis: SEED's First Year Executive Summary “ Poverty is the biggest issue. Everything we deal with stems from that. There’s so many people working incredibly hard, and if life happens, there’s no bottom. “ —Michael D. Tubbs The Stockton Economic Empowerment Key Findings Include: Demonstration, or SEED, was the nation’s • Guaranteed income reduced income volatility, first mayor-led guaranteed income initiative. or the month-to-month income fluctuations Launched in February 2019 by former Mayor that households face. Michael D. Tubbs, SEED gave 125 Stocktonians $500 per month for 24 months. The cash was • Unconditional cash enabled recipients unconditional, with no strings attached and no to find full-time employment. work requirements. • Recipients of guaranteed income were This Randomized Control Trial (RCT) pilot is being healthier, showing less depression and anxiety evaluated by a team of independent researchers, and enhanced wellbeing. Dr. Stacia West of the University of Tennessee • The guaranteed income alleviated financial and Dr. Amy Castro Baker of the University of scarcity creating new opportunities for Pennsylvania, and funded by the Evidence for self-determination, choice, goal-setting, Action Program at the Robert Wood Johnson and risk-taking. Foundation. SEED sought to confront, address, and humanize Our primary research questions are the following: some of the most pressing and pernicious How does guaranteed income impact problems our country faces: inequality, income income volatility? How do changes in income volatility, and poverty.
    [Show full text]
  • Comparative Study of Cryptographic Encryption Algorithms
    IOSR Journal of Electronics and Communication Engineering (IOSR-JECE) e-ISSN: 2278-2834,p- ISSN: 2278-8735.Volume 12, Issue 3, Ver. II (May - June 2017), PP 66-71 www.iosrjournals.org Comparative Study of Cryptographic Encryption Algorithms Chaitra B1, Kiran Kumar V.G.1, Shantharama Rai C2 1(Electronics & Communication Engineering, Sahyadri College of Engineering& Management, India) 1(Associate Professor Electronics & Communication Engineering, Sahyadri College of Engineering & Management, India) 2(Principal,, AJ Institute of Engineering &Technology, Mangaluru, India) Abstract: Protection of the network to enhance the safety of the information is great challenge in cryptography. With the developments in the cryptography lightweight cryptography has large space towards security by its simplicity in the implementations. For majority of applications PRESENT and TEA are excellent and preferred choices. However PRESENT is suitable for low constrained devices like RFID tags and sensor network. In this paper we describe ultra-lightweight cryptographic algorithms in detail. Both efficiency and security of information are important while designing and implementation considering security, cost and performance. The efficiency of PRESENT and TEA are higher as they have ability to resist cryptographic attacks and also due to their adequate security. In this paper the performance analysis of PRESENT and Tea are described. I. Introduction In digital era secrecy of the information plays important role in cryptography. Cryptography is the integral part of communication organization. PRESENT is newly introduced lightweight cryptographic algorithm. It is mainly designed for devices which have extremely low constrained resources in terms of area power and time. If we relate the performance analysis with other PRESENT is better block ciphers.
    [Show full text]
  • New Comparative Study Between DES, 3DES and AES Within Nine Factors
    JOURNAL OF COMPUTING, VOLUME 2, ISSUE 3, MARCH 2010, ISSN 2151-9617 152 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/ New Comparative Study Between DES, 3DES and AES within Nine Factors Hamdan.O.Alanazi, B.B.Zaidan, A.A.Zaidan, Hamid A.Jalab, M.Shabbir and Y. Al-Nabhani ABSTRACT---With the rapid development of various multimedia technologies, more and more multimedia data are generated and transmitted in the medical, also the internet allows for wide distribution of digital media data. It becomes much easier to edit, modify and duplicate digital information .Besides that, digital documents are also easy to copy and distribute, therefore it will be faced by many threats. It is a big security and privacy issue, it become necessary to find appropriate protection because of the significance, accuracy and sensitivity of the information. , which may include some sensitive information which should not be accessed by or can only be partially exposed to the general users. Therefore, security and privacy has become an important. Another problem with digital document and video is that undetectable modifications can be made with very simple and widely available equipment, which put the digital material for evidential purposes under question. Cryptography considers one of the techniques which used to protect the important information. In this paper a three algorithm of multimedia encryption schemes have been proposed in the literature and description. The New Comparative Study between DES, 3DES and AES within Nine Factors achieving an efficiency, flexibility and security, which is a challenge of researchers. Index Terms—Data Encryption Standared, Triple Data Encryption Standared, Advance Encryption Standared.
    [Show full text]
  • Cryptography Overview Cryptography Basic Cryptographic Concepts Five
    CS 155 Spring 2006 Cryptography Is A tremendous tool Cryptography Overview The basis for many security mechanisms Is not John Mitchell The solution to all security problems Reliable unless implemented properly Reliable unless used properly Something you should try to invent yourself unless you spend a lot of time becoming an expert you subject your design to outside review Basic Cryptographic Concepts Five-Minute University Encryption scheme: functions to encrypt, decrypt data key generation algorithm Secret key vs. public key -1 Public key: publishing key does not reveal key -1 Father Guido Sarducci Secret key: more efficient, generally key = key Hash function, MAC Everything you could remember, five Map input to short hash; ideally, no collisions MAC (keyed hash) used for message integrity years after taking CS255 … ? Signature scheme Functions to sign data, verify signature Web Purchase Secure communication 1 Secure Sockets Layer / TLS SSL/TLS Cryptography Standard for Internet security Public-key encryption Key chosen secretly (handshake protocol) Originally designed by Netscape Key material sent encrypted with public key Goal: “... provide privacy and reliability between two communicating applications” Symmetric encryption Two main parts Shared (secret) key encryption of data packets Signature-based authentication Handshake Protocol Client can check signed server certificate Establish shared secret key using public-key cryptography Signed certificates for authentication And vice-versa, in principal Record
    [Show full text]
  • A (Second) Preimage Attack on the GOST Hash Function
    A (Second) Preimage Attack on the GOST Hash Function Florian Mendel, Norbert Pramstaller, and Christian Rechberger Institute for Applied Information Processing and Communications (IAIK), Graz University of Technology, Inffeldgasse 16a, A-8010 Graz, Austria [email protected] Abstract. In this article, we analyze the security of the GOST hash function with respect to (second) preimage resistance. The GOST hash function, defined in the Russian standard GOST-R 34.11-94, is an iter- ated hash function producing a 256-bit hash value. As opposed to most commonly used hash functions such as MD5 and SHA-1, the GOST hash function defines, in addition to the common iterated structure, a check- sum computed over all input message blocks. This checksum is then part of the final hash value computation. For this hash function, we show how to construct second preimages and preimages with a complexity of about 2225 compression function evaluations and a memory requirement of about 238 bytes. First, we show how to construct a pseudo-preimage for the compression function of GOST based on its structural properties. Second, this pseudo- preimage attack on the compression function is extended to a (second) preimage attack on the GOST hash function. The extension is possible by combining a multicollision attack and a meet-in-the-middle attack on the checksum. Keywords: cryptanalysis, hash functions, preimage attack 1 Introduction A cryptographic hash function H maps a message M of arbitrary length to a fixed-length hash value h. A cryptographic hash function has to fulfill the following security requirements: – Collision resistance: it is practically infeasible to find two messages M and M ∗, with M ∗ 6= M, such that H(M) = H(M ∗).
    [Show full text]
  • AES and 3-DES Encryption Support for SNMP Version 3
    AES and 3-DES Encryption Support for SNMP Version 3 The AES and 3-DES Encryption Support for SNMP Version 3 feature enhances the encryption capabilities of Simple Network Management Protocol (SNMP) Version 3. The AES and 3-DES Encryption Support for SNMP Version 3 feature adds Advanced Encryption Standard (AES) 128-bit encryption in compliance with RFC 3826. • Finding Feature Information, on page 1 • Prerequisites for AES and 3-DES Encryption Support for SNMP Version 3, on page 1 • Information About AES and 3-DES Encryption Support for SNMP Version 3, on page 2 • How to Configure AES and 3-DES Encryption Support for SNMP Version 3, on page 3 • Additional References , on page 5 • Feature Information for AES and 3-DES Encryption Support for SNMP Version 3, on page 6 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to https://cfnng.cisco.com/. An account on Cisco.com is not required. Prerequisites for AES and 3-DES Encryption Support for SNMP Version 3 • The network management station (NMS) must support Simple Network Management Protocol (SNMP) Version 3 to be able to use this feature.
    [Show full text]
  • Camellia: a 128-Bit Block Cipher Suitable for Multiple Platforms – Design Andanalysis
    Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms – Design andAnalysis Kazumaro Aoki1, Tetsuya Ichikawa2, Masayuki Kanda1, Mitsuru Matsui2, Shiho Moriai1, Junko Nakajima2, and Toshio Tokita2 1 Nippon Telegraph and Telephone Corporation, 1-1 Hikarinooka, Yokosuka, Kanagawa, 239-0847Japan {maro,kanda,shiho}@isl.ntt.co.jp 2 Mitsubishi Electric Corporation, 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501 Japan {ichikawa,matsui,june15,tokita}@iss.isl.melco.co.jp Abstract. We present a new 128-bit block cipher called Camellia. Camellia supports 128-bit block size and 128-, 192-, and 256-bit keys, i.e., the same interface specifications as the Advanced Encryption Stan- dard (AES). Efficiency on both software and hardware platforms is a remarkable characteristic of Camellia in addition to its high level of se- curity. It is confirmed that Camellia provides strong security against differential and linear cryptanalyses. Compared to the AES finalists, i.e., MARS, RC6, Rijndael, Serpent, and Twofish, Camellia offers at least comparable encryption speed in software and hardware. An optimized implementation of Camellia in assembly language can encrypt on a Pen- tium III (800MHz) at the rate of more than 276 Mbits per second, which is much faster than the speed of an optimized DES implementation. In addition, a distinguishing feature is its small hardware design. The hard- ware design, which includes encryption and decryption and key schedule, occupies approximately 11K gates, which is the smallest among all ex- isting 128-bit block ciphers as far as we know. 1 Introduction This paper presents a 128-bit block cipher called Camellia, which was jointly developed by NTT and Mitsubishi Electric Corporation.
    [Show full text]
  • A Comparison of Cryptographic Algorithms: DES, 3DES, AES, RSA
    www.symbiosisonline.org www.symbiosisonlinepublishing.com Symbiosis ISSN Online: 2474-9257 Research Article Journal of Computer Science Applications and Information Technology Open Access A Comparison of Cryptographic Algorithms: DES, 3DES, AES, RSA and Blowfish for Guessing Attacks Prevention Mohammed Nazeh Abdul Wahid*, Abdulrahman Ali, Babak Esparham and Mohamed Marwan Limkokwing University of Creative and Technology, Post Graduate Centre, Cyberjaya, Malaysia Received: June 22, 2018; Accepted: July 12, 2018; Published: August 10, 2018 *Corresponding author: Mohammed Nazeh Abdul Wahid, Senior Lecturer, Limkokwing university of creative technology, Post Graduate Centre, Cyberjaya, Malaysia, Tel: +60104339985; E-mail: [email protected] Abstract Encryption is the process of encoding information or data in key (also called secret-key) and Asymmetric-key (called public- order to prevent unauthorized access. These days we need to secure key) encryption [2]. the information that is stored in our computer or is transmitted via evaluation is a network security system for an application using internet against attacks. There are different types of cryptographic the Aproposed secure Wi-Fi algorithm. system As for for wireless some cryptographicnetworks: experimental system, it methods that can be used. Basically, the selecting cryptographic is commonly used to secure communication channels by using method depends on the application demands such as the response public key exchanges based on algorithms such as RSA, DES, AES, cryptographic algorithms has its own weak and strong points. In this paper,time, bandwidth,we will present confidentiality the result of and the implementationintegrity. However, and analysiseach of the key used to encrypt data sent over an unsecured Internet that applied on several cryptographic algorithms such as DES, 3DES, channel.Triple DES In andaddition, Blowfish.
    [Show full text]