Friday, October 21, 2011

Baseline Requirements for the Publicly trusted CA's.

The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates describe a subset of the requirements that a Certification Authority must meet in order to issue Publicly Trusted Certificates. Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date.

These Requirements do not address all of the issues relevant to the issuance and management of Publicly-Trusted Certificates. The CA/Browser Forum may update the Requirements from time to time, in order to address both existing and emerging threats to online security. In particular, it is expected that a future version will contain more formal and comprehensive audit requirements for delegated functions.

This Requirement only addresses Certificates intended to be used for authenticating servers accessible through the Internet. Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions.

These Requirements do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier.

Continue Reading ..Baseline Requirements for the Publicly trusted CA's.


The SSL protocol is a security protocol that sits on top of TCP at the transport layer. In the OSI model, application layer protocols such as HTTP or IMAP, handle user application tasks such as displaying web pages or running email servers.
Session layer protocols establish and maintain communications channels. Transport layer protocols such as TCP and UD P, handle the flow of data between two hosts. Network layer protocols such as IP and ICMP provide hop-by-hop handling of data packets across the network.
SSL operates independently and transparently of other protocols so it works with any application layer and any transport layer protocol. This allows clients and servers to establish secure SSL connections without requiring knowledge of the other party’s code.
Reference: Bluecoat

Tuesday, October 18, 2011

Key Management Plan: - What needs to be included!!

Key Management Plan, though keys are widely used in various of domains like ATM, HSM, IPSec Tunnel, VPN Tunnels and many others, ways of managing those keys are not widely mentioned. Part of my role is to provide clients with procedures that they could use to manage and maintain the safes.. Lack of defined structure and clarity enables confusion so this is my attempt to standardise the life cycle of sensitive Symmetric Keys.
The Life cycle includes Key Generation, Key Transfer/Conveyance, Key Storage, Key Accounting, Key Destruction, Key Archival and compromise.
High Level Logical Process
  • Provide the high level process to describe the overall cryptographic work flow. Right from task initiation to the different environment the keys or certificate flow into and expected outcome.
  • Provide the high level diagram on different aspects involved and the order the work flows.
Key Generation Process:
  • Provide dates; location details if appropriate.
  • Provide a description of how the key(s) will be sourced. This may be via another agency or may be key(s) generation processes or equipment. It may be required to provide details of the initial key generation or seeding.
  • Provide details on how the key is to be physically loaded into the hardware and/or software cryptographic system.
  • Provide details on how the key(s) are produced and distributed to the relevant parties.
  • Describe how the key(s) are to be used, to the extent that this information is not already covered in sections earlier. Include the following:
  • When encryption and decryption occurs;
  • What data is to be encrypted and decrypted; and
  • The keys and algorithms are to be used in these transformations.
  • Detail the crypto period(s) for the various key(s).
  • Provide details of how the key(s) will be electronically and physically stored. Include security countermeasures that will be used to protect the key(s) from compromise.
Key Accounting:
  • Detail the number of copies of key to be produced and distributed to the various parties.
  • Provide details on the identification of the various key(s) to be produced and/or receipted.
  • Detail the procedures for labelling and recording of the name, version and number of copies that were distributed, and the recipients of the key(s).
  • If appropriate, detail how key(s) are to be destroyed.
  • Provide detailed inventory of various types of key involved with key name, length and type.
Key Distribution 
  • Provide details on how keys will be distributed electronically or physically. This should include security details of courier(s), if used, as well as how the couriers will handle contingencies such as loss or compromise of keys. Electronic distribution of keys may already have been discussed in the section titled "Key Management" above.
Key Contingency 
  • Describe the conditions under which a compromise of cryptographic key material should be declared. This should include loss or theft of keying material, unauthorised access to keys or equipment, and unauthorised extensions of crypto periods.
  • Describe the reporting action that is to be effected as part of a compromise declaration. This should include the addressees of the report, the details of the minimum amount of information that should be included in the report, and any action that is or will be taken to further scope the compromise and/or limit the exposure.
  • Detail the procedures for recovery of keys and encrypted material.
Key Compromise 
  • Detail the key compromise procedure on how the incident will be investigated and how to escalate the incident.
  • Detail some event which is considered as compromise
  • Whenever the HSM is replaced
  • The physical appearance of the HSM indicates a possible tamper
  • The tamper indicator on the HSM is flashing
  • Any safe is unexpectedly found open
  • Any safe is inadvertently left open and unattended by a custodian
  • The seal on an envelope containing a part of the key component is broken
  • The HSM does not accept or validate one or more steps in any key creation or loading procedure
  • The HSM does not accept an authentication attempt from a previously used custodian smartcard
  • Detail the escalation procedure on whom to contact in terms of incident. .
Key Destruction
  • Keys and their bound metadata should be destroyed when they no longer to be used. Destroying a key in a high security application can be a complex process, depending on the storage media of the key. Keys in electronic storage media may be overwritten with zeros or random patterns of zeros and ones repeatedly in a prescribed manner. Magnetic media that has a propensity for retaining low levels of magnetism may be physically destroyed, degaussed, or over-written with various bit patterns numerous times.
  • Provide explanation/procedure on the circumstance under which a key may be destroyed.
Key Archival
  • Key archive involves placing a key in a safe long-term storage facility so that it can be retrieved when needed. Key archiving usually requires provisions for moving the key to new storage media when the old media are no longer readable because of ageing of, or technical changes to, the media readers. Archived keys should be automatically retrieved from the old storage medium and restored on the new storage medium when a storage medium replacement is made.
  • The KMS design shall specify how, where, and the circumstances under which keys and their bound metadata are archived.
Key retrieval
  • Obtaining a cryptographic key from storage, a backup facility, or an archive is considered retrieval if done during normal KMS operation. If there has been an environmental or man-made disaster and the key cannot be normally retrieved and used, the key may have to be recovered by special means or with special permission. The KMS security policy should state the conditions under which a key may be retrieved normally.
  • The KMS design shall specify how, and the circumstances under which, keys and their bound metadata may be retrieved from a key database storage facility.
Key Escrow
  • Key escrow involves providing copies or components of secret or private keys to trusted parties so that the key owner or other authorised parties can recover the key when the owner’s key is destroyed or otherwise unavailable.
  • The KMS design shall specify the security policy (e.g., continuous two-person control) for the protection of escrowed keys.
  • The KMS design shall specify how the security policy is implemented during the key escrow, i.e., how the confidentiality and multi-party control requirements are implemented during transport and storage of the escrowed key.
Hardware and/or Software Maintenance 
  • Detail the maintenance procedures for hardware and/or software items that are critical to successful operation of the cryptographic services. This should include the security measures taken to protect the integrity of the hardware and/or software by uncleared maintenance staff, as well as ensuring hardware and/or software has been adequately sanitised prior to release.
  • Detail the procedures for testing or verification of software upgrades to critical cryptographic services in either the hardware (through firmware) or software.
Key Resources
  • Provide a description of the resources required for operating, maintaining, and supporting the system once it is put into production. Roles to consider include any key custodians, support groups, and any business roles etc.
  • Outlining the risk aspect of the keys with likelihood, consequences and impact for various likely scenario needed to be outlined.
  • Key conveyance and Key Destruction must be tracked either as soft-copy or hard copy, so its best practise to use standard Key conveyance forms/ Key Destruction forms and file them for record purposes.

Sunday, October 2, 2011

PIN Security and Key Management Control based guidelines

I found this document on PIN Security and Key Management from controls and audit perspective...
Billions of PIN activated transactions are switched through shared ATM and POS networks each year. Each of these transactions is originated using a debit or credit card and Personal Identification Number. With each interchange transaction, the security of the customer's PIN is under the control of as many as eight or more processing entities. The financial institution, which issues the card, must rely on the security procedures and controls of the acquiring entities with which the card issuer may not have any business relationship.
The number of interchange transactions is increasing, as is the number of organizations processing interchange transactions (merchants, merchant processors, financial institution processors, third party processors, and switches). As the number of organizations involved in processing interchange transactions increases, so does the risk to financial institutions due to ineffective or inadequate security systems and procedures at the acquiring or intermediary systems.
Regional and national interchange networks generally mandate security requirements in their operating rules and procedures. Historically, reviewing security procedures and systems for compliance to the network operating rules was left to the network member or processor. Because the technical expertise in the area of EFT security can vary greatly between and within organizations, the depth of the review can vary greatly. In order to standardize the process for reviewing security processes and procedures, and to eliminate unnecessary redundant compliance documents throughout the industry, this PIN Security Compliance Guideline has been developed.