#include "include/jmemblob.h"
Detailed Description
Offline key protection with Memory Blobs (BLOB)
Class to encapsulate memory blobs for offline key storage
The methods and constructor for memory BLOBs are as follows
See NIST Publication 800-57 Part 1 Recommendation for Key Management Section 8.3 and Appendix B
The memory BLOB supports the Post-Operational Phase of Key Management found in the publication
Post-Operational Phase
During the post-operational phase, keying material is no longer in operational use, but access to the keying material may still be possible
Key Archive and Key Recovery Functions
A key archive is a repository containing keys and their associated information (i.e., key information) for recovery beyond the cryptoperiod of the keys. Not all keys need to be archived. An organization’s security plan should discuss key archiving (see SP 800-57, Part 2)
The key archive shall continue to provide the appropriate protections for each key and any other related information in the archive as specified in Section 6.2.2. The archive will require a strong access-control mechanism to limit access to only authorized entities When key information is entered into the archive, it is often timestamped so that the date of entry can be determined. This date may itself be cryptographically protected so that it cannot be changed without detection
If a key must be recoverable (e.g., after the end of its cryptoperiod), either the key shall be archived, or the system shall be designed to allow reconstruction (e.g., re-derivation) of the key from archived information. Retrieving the key from archive storage or by reconstruction is commonly known as key recovery. The archive shall be maintained by a trusted party (e.g., the organization associated with the key or a trusted third party)
Archived key information shall be stored separately from operational data, and multiple copies of archived key information should be provided in physically separate locations (i.e., the key archive should be backed up). For critical information that is encrypted under archived keys, it may be necessary to back up the archived keys and store multiple copies of these archived keys in separate locations
When archived, keys should be archived prior to the end of the key’s cryptoperiod. For example, it may be prudent to archive the key when it is activated. When no longer required, the key shall be destroyed in accordance with Section 8.3.4 of the Post-Operational Phase
The confidentiality of archived key information is provided by an archive-encryption key (one or more encryption keys that are used exclusively for the encryption of archived key information), by another key that has been archived, or by a key that may be derived from an archived key. Note that the algorithm with which the archive-encryption key is used may also provide integrity protection for the encrypted information
When the archive-encryption key and its associated algorithm do not also provide integrity protection for the encrypted information, integrity protection shall be provided by a separate archive-integrity key (i.e., one or more authentication or digital-signature keys that are used exclusively for the archive) or by another key that has been archived
When the confidentiality and integrity protection of the archived key information are provided using separate processes, the archive-encryption key and archive-integrity key shall be different from each other (e.g., independently generated) and shall be protected in the same manner as their key type (see Section 6.1.1). Note that these two services could also be provided using authenticated encryption, which uses a single cryptographic algorithm operation and a single key
Tables 9 and 10 indicate the appropriateness of archiving keys and other cryptographically related information. An “OK” in column 2 (Archive?) indicates that archiving is permissible but not necessarily required. Column 3 (Retention period) indicates the minimum time that the key should be retained in the archive. Additional advice on the storage of keying material in archive storage is provided in Appendix B.3
The recovery of archived keying material may be required to remove (e.g., decrypt) or check (e.g., verify a digital signature or a MAC) the cryptographic protections on other archived data; recovered keys shall not be used to apply cryptographic protection if the cryptoperiod (or originator-usage period) of those keys has expired. The key-recovery process results in retrieving or reconstructing the desired keying material from archive storage in order to perform the required cryptographic operation. Immediately after completing this operation, the keying material shall be erased from the cryptographic process102 for which it was recovered (i.e., it shall not be used for normal operational activities). However, the key shall be retained in the archive (see Section 8.3.4) as long as needed. Further advice on key-recovery issues is provided in Appendix B
For API Documentation:
- See also
- ProtocolPP::jsecass
- ProtocolPP::jmemblobsa
- ProtocolPP::jmemblob
- ProtocolPP::jarray
- ProtocolPP::jenum
For Additional Documentation:
The source code contained or described herein and all documents related to the source code (herein called "Material") are owned by John Peter Greninger and Sheila Rocha Greninger. Title to the Material remains with John Peter Greninger and Sheila Rocha Greninger. The Material contains trade secrets and proprietary and confidential information of John Peter Greninger and Sheila Rocha Greninger. The Material is protected by worldwide copyright and trade secret laws and treaty provisions. No part of the Material may be used, copied, reproduced, modified, published, uploaded, posted, transmitted, distributed, or disclosed in any way without prior express written consent of John Peter Greninger and Sheila Rocha Greninger (both are required)
No license under any patent, copyright, trade secret, or other intellectual property right is granted to or conferred upon you by disclosure or delivery of the Materials, either expressly, by implication, inducement, estoppel, or otherwise. Any license under such intellectual property rights must be express and approved by John Peter Greninger and Sheila Rocha Greninger in writing
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution
- Any and all modifications must be returned to John Peter Greninger at GitHub.com https://github.com/jpgreninger/protocolpp for evaluation. Inclusion of modifications in the source code shall be determined solely by John Peter Greninger. Failure to provide modifications shall render this license NULL and VOID and revoke any rights to use of Protocol++®
- Commercial use requires a fee-based license obtainable at www.protocolpp.com
- Academic use requires written and notarized permission from John Peter and Sheila Rocha Greninger
- US Copyrights at https://www.copyright.gov/
The documentation for this class was generated from the following file:
- include/jmemblob.h
