Version | Date | Comment |
---|---|---|
4.2.1 | 2019-04-22 | Formatting changes as a result of PP evaluation |
4.2 | 2018-05-22 | Multiple Technical Decisions applied |
4.1 | 2016-03-09 | Minor updates - cryptographic modes |
4.0 | 2015-08-14 | Release - significant revision |
Address Space Layout Randomization (ASLR) | An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of a process. |
Administrator | An administrator is responsible for management activities, including setting policies that are applied by the enterprise on the operating system. This administrator could be acting remotely through a management server, from which the system receives configuration policies. An administrator can enforce settings on the system which cannot be overridden by non-administrator users. |
Application (app) | Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. |
Application Programming Interface (API) | A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform. |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Credential | Data that establishes the identity of a user, e.g. a cryptographic key or password. |
Critical Security Parameters (CSP) | Information that is either user or system defined and is used to operate a cryptographic module in processing encryption functions including cryptographic keys and authentication data, such as passwords, the disclosure or modification of which can compromise the security of a cryptographic module or the security of the information protected by the module. |
Data At Rest (DAR) Protection | Countermeasures that prevent attackers, even those with physical access, from extracting data from non-volatile storage. Common techniques include data encryption and wiping. |
Data Execution Prevention (DEP) | An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code. |
Developer | An entity that writes OS software. For the purposes of this document, vendors and developers are the same. |
Extended Package (EP) | An implementation-independent set of security requirements for a specific subset of products described. |
General Purpose Operating System | A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services. Typical characteristics for OSes in this class include support for third-party applications, support for multiple users, and security separation between users and their respective resources. General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems (RTOS). RTOSes typically power routers, switches, and embedded devices. |
Host-based Firewall | A software-based firewall implementation running on the OS for filtering inbound and outbound network traffic to and from processes running on the OS. |
Operating System (OS) | Software that manages physical and logical resources and provides services for applications. The terms TOE and OS are interchangeable in this document. |
Personally Identifiable Information (PII) | Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother's maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. [OMB] |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Sensitive Data | Sensitive data may include all user or enterprise data or may be specific application data such as PII, emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include credentials and keys. Sensitive data shall be identified in the OS's TSS by the ST author. |
Target of Evaluation (TOE) | The product under evaluation. In this case, the Operating System as described in section Section 1.3.1 TOE Boundary and its supporting documentation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in a ST. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
User | A user is subject to configuration policies applied to the operating system by administrators. On some systems under certain configurations, a normal user can temporarily elevate privileges to that of an administrator. At that time, such a user should be considered an administrator. |
The OS provides a platform for end user devices such as desktops, laptops, convertibles, and tablets. These devices may optionally be bound to a directory server or management server.
As this Protection Profile does not address threats against data-at-rest, enterprises deploying operating systems in mobile scenarios should ensure that these systems include data-at-rest protection spelled out in other Protection Profiles. Specifically, this includes the Protection Profiles for Full Drive Encryption - Encryption Engine, Full Drive Encryption - Authorization Acquisition, and Software File Encryption. The Protection Profile for Mobile Device Fundamentals includes requirements for data-at-rest protection and is appropriate for many mobile devices.
The OS provides a platform for providing cloud services running on physical or virtual hardware. An OS is typically part of offerings identified as Infrastructure as a Service (IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS).
This use case typically involves the use of virtualization technology which should be evaluated against the Protection Profile for Server Virtualization.
The ST may iterate any of these components, but it must not include any additional component (e.g. from [CC] Part 2 or 3 or a PP not conformant with this one, or extended by the ST) not defined in this PP or a PP conformant to this one.
Some components in this Protection Profile have a dependency on other components. In accordance with [CC] Part 1, Appendix D - Implicitly Satisfied Requirements includes justifications for those cases where the PP does not explicitly contain the component upon which there is a dependency.
Threat, Assumption, or OSP | Security Objectives | Rationale |
T.NETWORK_ATTACK | O.PROTECTED_COMMS, O.INTEGRITY, O.MANAGEMENT, O.ACCOUNTABILITY | The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this
provides for integrity of transmitted data. The threat T.NETWORK_ATTACK is countered by O.INTEGRITY as this provides for integrity of software that is installed onto the system from the network. The threat T.NETWORK_ATTACK is countered by O.MANAGEMENT as this provides for the ability to configure the OS to defend against network attack. The threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this provides a mechanism for the OS to report behavior that may indicate a network attack has occurred. |
T.NETWORK_EAVESDROP | O.PROTECTED_COMMS, O.MANAGEMENT | The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this
provides for confidentiality of transmitted data. The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides for the ability to configure the OS to protect the confidentiality of its transmitted data. |
T.LOCAL_ATTACK | O.INTEGRITY, O.ACCOUNTABILITY | The objective O.INTEGRITY protects against the use of mechanisms that weaken
the TOE with regard to attack by other software on the
platform. The objective O.ACCOUNTABILITY protects against local attacks by providing a mechanism to report behavior that may indicate a local attack is occurring or has occurred. |
T.LIMITED_PHYSICAL_ACCESS | O.PROTECTED_STORAGE | The objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE. |
A.PLATFORM | OE.PLATFORM | The operational environment objective OE.PLATFORM is realized through A.PLATFORM. |
A.PROPER_USER | OE.PROPER_USER | The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. |
A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
The ST author shall select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.
If the OS acts only as a receiver in the RSA key establishment scheme, the OS does not need to implement RSA key generation.
The ST author shall select all key establishment schemes used for the selected cryptographic protocols. FCS_TLSC_EXT.1 requires cipher suites that use RSA-based key establishment schemes.
The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the OS acts as a receiver in the RSA key establishment scheme, the OS does not need to implement RSA key generation.
The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1. The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1.
The interface referenced in the requirement could take different forms, the most likely of which is an application programming interface to an OS kernel. There may be various levels of abstraction visible. For instance, in a given implementation, selection a, the application may have access to the file system details and may be able to logically address specific memory locations. In another implementation, selection b, the application may simply have a handle to a resource and can only ask the platform to delete the resource, as may be the case with a platforms secure key store. Selection b should only be used for the most restricted access. The level of detail to which the TOE has access will be reflected in the TSS section of the ST.
Several selections allow assignment of a 'value that does not contain any CSP'. This means that the TOE uses some other specified data not drawn from a source that may contain key material or reveal information about key material, and not being any of the particular values listed as other selection options. The point of the phrase 'does not contain any CSP' is to ensure that the overwritten data is carefully selected, and not taken from a general 'pool' that might contain current or residual data that itself requires confidentiality protection.
For the purposes of this requirement, key material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc.
Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1.
AES CCMP (which uses AES in CCM as specified in SP 800-38C) becomes mandatory and must be selected if the ST includes the WLAN Client EP.
For the second selection, the ST author should choose the mode or modes in which AES operates. For the third selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit key size is required in order to comply with FCS_TLSC_EXT.1 and FCS_CKM.1, if those are selected.
Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.
SHA-1 is currently required in order to comply with FCS_TLSC_EXT.1 and, depending on selections, FCS_DTLS_EXT.1. Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A.
The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used.
The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the OS (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1(1). Though HMAC with SHA-256 (HMAC-SHA-256) is listed as a selectable cipher suite in this requirement, FCS_TLSC_EXT.1 effectively makes its implementation mandatory for compliant OSes.
SHA-1 is currently required in order to comply with FCS_TLSC_EXT.1 and, depending on selections, FCS_DTLS_EXT.1. SHA-1 is currently required in order to comply with FCS_TLSC_EXT.1, but has been deprecated and should not be used for any other purpose beyond TLS and DTLS
For the first selection in this requirement, the ST author selects 'software-based noise source' if any additional noise sources are used as input to the DRBG.
In the second selection in this requirement, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits), AES 128 (security strength 128 bits), and HMAC-SHA-256 (security strength 256 bits), then the ST author would select 256 bits.
The cipher suites to be tested in the evaluated configuration are limited by this requirement. The ST author should select the optional cipher suites that are supported; if there are no cipher suites supported other than the mandatory suites, then "No other cipher suite" should be selected. It is necessary to limit the cipher suites that can be used in an evaluated configuration administratively on the server in the test environment. The Suite B algorithms listed above (RFC 6460) are the preferred algorithms for implementation. TLS_RSA_WITH_AES_128_CBC_SHA is required in order to ensure compliance with RFC 5246.
These requirements will be revisited as new TLS versions are standardized by the IETF.
If any cipher suites are selected using ECDHE, then FCS_TLSC_EXT.2 is required.
The rules for verification of identity are described in Section 6 of RFC 6125. The reference identifier is established by the user (e.g. entering a URL into a web browser or clicking a link), by configuration (e.g. configuring the name of a mail server or authentication server), or by an application (e.g. a parameter of an API) depending on the OS service. Based on a singular reference identifier's source domain and application service type (e.g. HTTP, SIP, LDAP), the client establishes all reference identifiers which are acceptable, such as a Common Name for the Subject Name field of the certificate and a (case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative Name field. The client then compares this list of all acceptable reference identifiers to the presented identifiers in the TLS server's certificate.
The preferred method for verification is the Subject Alternative Name using DNS names, URI names, or Service Names. Verification using the Common Name is required for the purposes of backwards compatibility. Additionally, support for use of IP addresses in the Subject Name or Subject Alternative name is discouraged, as against best practices, but may be implemented. Finally, the client should avoid constructing reference identifiers using wildcards. However, if the presented identifiers include wildcards, the client must follow the best practices regarding matching; these best practices are captured in the evaluation activity.
Validity is determined by the identifier verification, certificate path, the expiration date, and the revocation status in accordance with RFC 5280. Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1.
For TLS connections, this channel shall not be established if the peer certificate is invalid.
Management Function | Administrator | User |
Enable/disable [selection: screen lock, session timeout] | XMandatory | OOptional |
Configure [selection: screen lock, session] inactivity timeout | XMandatory | OOptional |
Configure local audit storage capacity | OOptional | OOptional |
Configure minimum password length | OOptional | OOptional |
Configure minimum number of special characters in password | OOptional | OOptional |
Configure minimum number of numeric characters in password | OOptional | OOptional |
Configure minimum number of uppercase characters in password | OOptional | OOptional |
Configure minimum number of lowercase characters in password | OOptional | OOptional |
Configure lockout policy for unsuccessful authentication attempts through [selection: timeouts between attempts, limiting number of attempts during a time period] | OOptional | OOptional |
Configure host-based firewall | OOptional | OOptional |
Configure name/address of directory server with which to bind | OOptional | OOptional |
Configure name/address of remote management server from which to receive management settings | OOptional | OOptional |
Configure name/address of audit/logging server to which to send audit/logging records | OOptional | OOptional |
Configure audit rules | OOptional | OOptional |
Configure name/address of network time server | OOptional | OOptional |
Enable/disable automatic software update | OOptional | OOptional |
Configure WiFi interface | OOptional | OOptional |
Enable/disable Bluetooth interface | OOptional | OOptional |
Enable/disable [assignment: list of other external interfaces] | OOptional | OOptional |
[assignment: list of other management functions to be provided by the TSF] | OOptional | OOptional |
The ST should indicate which of the optional management functions are implemented in the TOE. This can be done by copying the above table into the ST and adjusting the "Administrator" and "User" columns to "X" according to which capabilities are present or not present, and for which privilege level. The Application Note for FMT_MOF_EXT.1 explains how to indicate Administrator or User capability.
The terms "Administrator" and "User" are defined in Section 1.2 Terms. The intent of this requirement is to ensure that the ST is populated with the relevant management functions that are provided by the OS.
Sophisticated account management policies, such as intricate password complexity requirements and handling of temporary accounts, are a function of directory servers. The OS can enroll in such account management and enable the overall information system to achieve such policies by binding to a directory server.
The bootchain of the OS is the sequence of software, to include the OS loader, the kernel, system drivers or modules, and system files, which ultimately result in loading the OS. The first part of the OS, usually referred to as the first-stage bootloader, must be loaded by the platform. Assessing its integrity, while critical, is the platform's responsibility; and therefore outside the scope of this PP. All software loaded after this stage is potentially within the control of the OS and is in scope.
The verification may be transitive in nature: a hardware-protected public key or hash may be used to verify the mutable bootloader code which contains a key or hash used by the bootloader to verify the mutable OS kernel code, which contains a key or hash to verify the next layer of executable code, and so on. However, the way in which the hardware stores and protects these keys is out of scope.
If all executable code (including bootloader(s), kernel, device drivers, pre-loaded applications, user-loaded applications, and libraries) is verified, "all executable code stored in mutable media" should be selected.
TRUE
for all CA certificates. This requirement ensures that all remote administrative actions are protected. Authorized remote administrators must initiate all communication with the OS via a trusted path and all communication with the OS by remote administrators must be performed over this path. The data passed in this trusted communication channel is encrypted as defined in FTP_ITC_EXT.1. If local users access is selected and no unprotected traffic is sent to remote users, then this requirement is met. If remote users access is selected, the ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST.
This requirement is tested with the evaluation activities for FTP_TRP.1.3.
This requirement is tested with the evaluation activities for FTP_TRP.1.3.
This requirement ensures that authorized remote administrators initiate all communication with the OS via a trusted path, and that all communication with the OS by remote administrators is performed over this path. The data passed in this trusted communication channel is encrypted as defined in FTP_ITC_EXT.1.
The evaluation activities for this requirement also test requirements FTP_TRP.1.1 and FTP_TRP.1.2.
The Security Objectives in Section 4 Security Objectives were constructed to address threats identified in Section 3.1 Threats. The Security Functional Requirements (SFRs) in Section 5.1 Security Functional Requirements are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.
This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual evaluation activities to be performed are specified both in Section 5 Security Requirements as well as in this section.
The general model for evaluation of OSes against STs written to conform to this PP is as follows:
After the ST has been approved for evaluation,
the
ITSEF
will obtain the OS, supporting environmental IT, and the administrative/user guides for
the OS. The ITSEF is expected to perform actions mandated by the Common Evaluation
Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the evaluation activities
contained within Section 5 Security Requirements, which are intended to be an interpretation of the
other CEM assurance requirements as they apply to the specific technology instantiated in the
OS. The evaluation activities that are captured in Section 5 Security Requirements also provide
clarification as to what the developer needs to provide to demonstrate the OS is compliant
with the PP.
Typically, the traffic required to establish the VPN connection is referred to as "Control Plane" traffic, whereas the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All Data Plane traffic must flow through the VPN connection and the VPN must not split-tunnel.
If no native IPsec client is validated or third-party VPN clients may also implement the required Information Flow Control, the first option shall be selected. In these cases, the TOE provides an API to third-party VPN clients that allows them to configure the TOE's network stack to perform the required Information Flow Control.
The ST author shall select the second option if the TSF implements a native VPN client (IPsec is selected in FTP_ITC_EXT.1). If the native VPN client is to be validated (IPsec is selected in FTP_ITC_EXT.1 and the TSF is validated against the EP for IPsec Virtual Private Network (VPN) Clients), the ST author shall also include FDP_IFC_EXT.1 from this package. In the future, this requirement may also make a distinction between the current requirement (which requires that when the IPsec trusted channel is enabled, all traffic from the TSF is routed through that channel) and having an option to force the establishment of an IPsec trusted channel to allow any communication by the TSF.
This appendix lists requirements that should be considered satisfied by products successfully evaluated against this Protection Profile. However, these requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the Protection Profile provides evidence that these controls are present and have been evaluated.
Requirement | Rationale for Satisfaction |
FIA_UAU.1 - Timing of authentication | FIA_AFL.1 implicitly requires that the OS perform all necessary actions, including those on behalf of the user who has not been authenticated, in order to authenticate; therefore it is duplicative to include these actions as a separate assignment and test. |
FIA_UID.1 - Timing of identification | FIA_AFL.1 implicitly requires that the OS perform all necessary actions, including those on behalf of the user who has not been identified, in order to authenticate; therefore it is duplicative to include these actions as a separate assignment and test. |
FMT_SMR.1 - Security roles | FMT_MOF_EXT.1 specifies role-based management functions that implicitly defines user and privileged accounts; therefore, it is duplicative to include separate role requirements. |
FPT_STM.1 - Reliable time stamps | FAU_GEN.1.2 explicitly requires that the OS associate timestamps with audit records; therefore it is duplicative to include a separate timestamp requirement. |
FTA_SSL.1 - TSF-initiated session locking | FMT_MOF_EXT.1 defines requirements for managing session locking; therefore, it is duplicative to include a separate session locking requirement. |
FTA_SSL.2 - User-initiated locking | FMT_MOF_EXT.1 defines requirements for user-initiated session locking; therefore, it is duplicative to include a separate session locking requirement. |
FAU_STG.1 - Protected audit trail storage | FPT_ACF_EXT.1 defines a requirement to protect audit logs; therefore, it is duplicative to include a separate protection of audit trail requirements. |
FAU_GEN.2 - User identity association | FAU_GEN.1.2 explicitly requires that the OS record any user account associated with each event; therefore, it is duplicative to include a separate requirement to associate a user account with each event. |
FAU_SAR.1 - Audit review | FPT_ACF_EXT.1.2 requires that audit logs (and other objects) are protected from reading by unprivileged users; therefore, it is duplicative to include a separate requirement to protect only the audit information. |
This appendix describes the required supplementary information for the entropy source used by the OS.
The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.
Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to include, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.
If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.
There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular OS). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the OS randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.
The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.
For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.
For third-party provided entropy sources, in which the OS vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to "assume" an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.
Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.
The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. |
[CESG] | CESG - End User Devices Security and Configuration Guidance |
[CSA] | Computer Security Act of 1987, H.R. 145, June 11, 1987. |
[OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |
[x509] | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008. |
Acronym | Meaning |
---|---|
AES | Advanced Encryption Standard |
API | Application Programming Interface |
ASLR | Address Space Layout Randomization |
CESG | Communications-Electronics Security Group |
CMC | Certificate Management over CMS |
CMS | Cryptographic Message Syntax |
CN | Common Names |
CRL | Certificate Revocation List |
CSA | Computer Security Act |
DEP | Data Execution Prevention |
DES | Data Encryption Standard |
DHE | Diffie-Hellman Ephemeral |
DNS | Domain Name System |
DRBG | Deterministic Random Bit Generator |
DSS | Digital Signature Standard |
DT | Date/Time Vector |
DTLS | Datagram Transport Layer Security |
EAP | Extensible Authentication Protocol |
ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
ECDSA | Elliptic Curve Digital Signature Algorithm |
EST | Enrollment over Secure Transport |
FIPS | Federal Information Processing Standards |
DSS | Digital Signature Standard |
HMAC | Hash-based Message Authentication Code |
HTTP | Hypertext Transfer Protocol |
HTTPS | Hypertext Transfer Protocol Secure |
DSS | Digital Signature Standard |
IETF | Internet Engineering Task Force |
IP | Internet Protocol |
ISO | International Organization for Standardization |
IT | Information Technology |
ITSEF | Information Technology Security Evaluation Facility |
NIAP | National Information Assurance Partnership |
NIST | National Institute of Standards and Technology |
OCSP | Online Certificate Status Protocol |
OID | Object Identifier |
OMB | Office of Management and Budget |
OS | Operating System |
PII | Personally Identifiable Information |
PKI | Public Key Infrastructure |
PP | Protection Profile |
RBG | Random Bit Generator |
RFC | Request for Comment |
RNG | Random Number Generator |
RNGVS | Random Number Generator Validation System |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
SHA | Secure Hash Algorithm |
S/MIME | Secure/Multi-purpose Internet Mail Extensions |
SIP | Session Initiation Protocol |
SWID | Software Identification |
TLS | Transport Layer Security |
URI | Uniform Resource Identifier |
URL | Uniform Resource Locator |
USB | Universal Serial Bus |
XCCDF | eXtensible Configuration Checklist Description Format |
XOR | Exclusive Or |