Operational Environments and OS Requirements for Modificable Operational Enviroments
This post is part of the Computer Security – Cryptography posts series.
Operational Environment
The requirements of this section apply only to modules containing software that run in a modifiable operational environment. The requirements do not apply to hardware only modules or anymodules with a non-modifiable operational environment.
The operational environment of a cryptographic module is the set of all software and hardware required for the module to operate securely. For example, the operational environment of a software module includes the module itself, the processor on which the software is executed, and the operating system that controls the execution of the software. An operational environment can be non-modifiable or modifiable.
A non-modifiable operational environment is designed to contain only validated software. This environment may be software operating in a non-programmable computer (e.g., a non-programmablecard or non-programmable smartcard), or software whose update is controlled using Approved data authentication processes (i.e., through the Software Load Test ). If the operenvironment is non-modifiable, then the operational environment components that enforce the nonmodifiability shall be bound to the software module.
A modifiable operational environment is designed to allow loading of non-validated software. This environment may include general purpose operating system capabilities (e.g., use of a computer O/S or configurable smart card O/S).
Operating systems are considered to be modifiable operational environments if software can be modified by the operator and/or the operator can load and execute software (e.g., a word processor) that was not included as part of the validation of the module.
If the operational environment is non-modifiable, the operating system requirements do not apply. If the operational environment is modifiable, the operating system requirements in shall apply. The goal of the requirements is to logically protect the cryptographic module running in a modifiable operational environment from unauthorized access (execute, modify or read) by untrusted processes.
Operating System Requirements
At Security Level 1 only, the operating system requirements are different for the cryptographic modules restricted to a single operator session at any given time and for those that allow multiple concurrent operators.
SECURITY LEVEL 1
The following requirements shall apply to operating systems restricted to a single operator session at any given time (i.e., concurrent operators are explicitly excluded) for Security Level 1.
- All MSI commands in a session shall be run on behalf of a single operator.
- All CSPs shall be zeroized before each operator’s session is terminated and a new operator’s session is begun.
- Processes that are spawned by the cryptographic module shall be owned by the module and shall not be owned by external processes/operators.
If the operating system allows multiple concurrent operators, then the following requirements apply:
- All cryptographic software, SSPs, and control and status information shall be under the control of an operating system that implements discretionary access controls that protect against unauthorized execution, modification, and reading.
- To protect plaintext data, cryptographic software, SSPs, and authentication data, the access control mechanisms of the operating system shall be configured to:
- Enforce the set of roles that can execute stored cryptographic software.
- Enforce the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software stored within the cryptographic boundary: cryptographic programs, cryptographic data (e.g., cryptographic audit data), SSPs, and plaintext data.
- Enforce the set of roles that can read the following cryptographic software stored within the cryptographic boundary: cryptographic data (e.g., cryptographic audit data), CSPs, and plaintext data.
- Enforce the set of roles that can enter SSPs.
- The following specifications shall be consistent with the roles and services as defined in the Security Policy.
- The operating system shall prevent all operators and executing processes from modifying executing cryptographic processes (i.e., loaded and executing cryptographic program images). In this case, executing processes refer to all non-operating system processes (i.e., operator-initiated), cryptographic or not.
- The operating system shall prevent operators from gaining either read or write access to SSPs of other operators.
- The operating system shall prevent operators and external executing processes from reading cryptographic software stored within the cryptographic boundary.
The configuration of the operating system to meet the above requirements shall be specified in a Crypto Officer guideline. The Crypto Officer guideline shall state that the operating system must be configured as specified, before the module contents can be considered as protected.
SECURITY LEVEL 2
In addition to the applicable requirements of Level 1 for the cryptographic modules that allow multiple concurrent operators, the following requirements shall apply for Security Level 2.
- The operating system shall provide an audit mechanism to record modifications, accesses, deletions, and additions of cryptographic data and SSPs. If audit information is stored outside of the module, then the module shall use Approved cryptographic mechanisms to protect the information when external to the module from unauthorized disclosure and modification.
- The following events shall be recorded by the audit mechanism:
- attempts to provide invalid input for Cryptographic Officer functions, and
- addition or deletion of an operator to and from a cryptographic Officer role.
- The audit mechanism shall be capable of auditing the following events:
- all operator read or write accesses to audit data stored in the audit trail,
- requests to use authentication data management mechanisms,
- the use of a security-relevant crypto officer function,
- requests to access authentication data associated with the cryptographic module,
- the use of an authentication mechanism (e.g., login) associated with the cryptographic module, and
- explicit requests to assume a crypto officer role.
- The following events shall be recorded by the audit mechanism:
- The module Security Policy shall specify whether identification and authentication of module operators is performed by operating system code or vendor supplied code.
SECURITY LEVEL 3
In addition to the applicable requirements for Security Level 2, the following requirements shall apply for Security Level 3.
The operating system shall be configured to prevent operators in the user role (if supported) from modifying cryptographic module software, system SSPs, and audit data stored within the operational environment of the module.
- A Trusted Channel shall be implemented between the authenticated operators and the cryptographic module.
- All SSPs, authentication data, control inputs, and status outputs shall be communicated via a Trusted Channel. Communications via this Trusted Channel shall be activated exclusively by an operator or the cryptographic module. The Trusted Channel shall provide source authentication and shall prevent unauthorized modification, substitution, disclosure, and playback of sensitive security parameters.
- In addition to the audit requirements of Security Level 2, the following events shall be recorded by the audit mechanism:
- o attempts to use the trusted channel function.
- o identification of the initiator and target of a trusted channel.
- Only operating systems that are permanently configured to meet the above security requirements shall be permitted at this security level whether in the Approved mode of operation or not.
SECURITY LEVELS 4 AND 5
In addition to the applicable requirements for Security Level 3, the following requirements shall apply for Security Levels 4 and 5.
- The audit mechanism shall be permanently configured so that the following events are always audited:
- all operator read or write accesses to audit data stored in the audit trail.
- requests to use authentication data management mechanisms.
- the use of a security-relevant Cryptographic Officer functions.
- requests to access authentication data associated with the cryptographic module.
26 Responses to “Operational Environments and OS Requirements for Modificable Operational Enviroments”
What’s the difference between the Diffie-Hellman and RSA ?
Diffie-Hellman is key exchange algorithm
RSA is encryption algorithm
How do I break a Vigenere cipher ?
If the plaintext is in English and the key is not too long , follow this steps:
1) Discover the length of the key by counting coincidences.Try each displacement of the ciphertext against itselfand count those bytes which are equal.
If the two ciphertext portions have used the same key, in general over 6% of the bytes will be equal. If they have used different keys, then less than 0.4% will be equal
The smallest displacement which indicates an equal key is the length of the repeated key.
2) Shift the text by that length and XOR it with itself. This removes the key and leaves you with text XORed with itself. Since English has about 1 bit of real information per byte, 2 streams of text XORed together has 2 bits of info per 8-bit byte, providing plenty of redundancy for choosing a unique decryption.
If the key is short, it might be even easier to treat this as a standard polyalphabetic substitution. All the old cryptanalysis texts show how to break those. It’s possible with those methods, in the hands of an expert, if there’s only ten times as much text as key.
How do I send encrypted mail under UNIX ?
Use this command:
cat file | compress | des private_key | uuencode | mail
What software is available in the public domain for mail encryption ?
Available are PGP and RIPEM.
RIPEM is most commonly used inside the USA and PGP outside the USA.
Exist an unbreakable cipher?
Yes. The one-time pad is unbreakable
What is the unicity distance ?
The unicity distance is an approximation to that amount of ciphertext such that the sum of the real information (entropy) in the corresponding source text and encryption key equals the number of ciphertext bits used.
What is key management ?
Key management refers to the distribution, authentication, and handling of keys.
What is a one-way hash function ?
A typical one-way hash function takes a variable-length message and produces a fixed-length hash.
What is the difference between public and private algorithm ?
When an algorithm depends on a key which isn’t published, we call it a private
algorithm; otherwise we call it a public algorithm.
What are MD4 and MD5?
MD4 and MD5 message-digest algorithms created by Ron Rivest.
The MD4 algorithm is fast on 32-bit machines and does not require any large substitution tables.
The MD5 algorithm is an extension of the MD4 message-digest algorithm and is slightly slower and more “conservative” in design.
What is MD5’s object identifier for OSI-based applications ?
MD5 OBJECT IDENTIFIER ::=iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5}
What are the steps for MD5 algorithm ?
The step are:
Append Padding Bits
Append Length
Initialize MD Buffer
Process Message in 16-Word Blocks
Output
interesting post
a very good article about Cryptographic Module – Operational Environment