The Payment Card Industry (PCI) Security Standard Council (SSC) require merchants and service providers to use industry standards and best practices for strong cryptography and secure protocols. The PCI SSC glossary defines strong cryptography as follows:-
Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). At the time of publication, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher).
They also refer to NIST documents on guidance on cryptographic key strengths and algorithms. A CISSP certified professional should be aware that cryptographic algorithms have a life-cycle; new stronger algorithms are introduced where the strength relates to the work factor and time need to break or brute force the keys for the algorithms. However, the strength of the cryptographic algorithms weakens with time as Moore’s law and other advances in computing reduce the work factor and time need to break or brute force the keys. Every cryptographic algorithm can be broken if the keys can be derived.
With recent vulnerabilities in SSL and TLS along with vulnerabilities in RC4, the PCI SSC has upped the boundary where strong cryptography can be considered to start. With PCI DSS v3.1 it has removed SSL and early TLS from new implementations and for existing implementation they must be removed by June 30th, 2016. For POS POI devices and the SSL/TLS endpoints, this can be done as long as they can be verified as not being susceptible to SSL/TLS exploits. For existing implementations using SSL and early TLS there must be a formal Risk Mitigation and Migration Plan in place. The PCI SSC have published guidance on migrating from SSL and Early TLS.
Versions of SSL & TLS
|
SSL v1
|
Netscape Proprietary protocol
|
Not published
|
|
SSL v2
|
Netscape Proprietary protocol
|
Published Feb 1995
|
|
SSL v2
|
Netscape Proprietary protocol
|
Published 1996
|
|
TLS v1.0
|
IETF Standard (RFC 2246)
|
Jan 1999
|
|
TLS v1.1
|
IETF Standard (RFC 4346)
|
Apr 2006
|
|
TLS v1.2
|
IETF Standard (RFC 5246)
|
Aug 2008
|
|
TLS v1.3
|
IETF Standard
|
Draft April 2015
|
The use of RC4 in all versions of TLS is prohibited by RFC 7465 due to attacks on the algorithm that weaken or break it. RFC 7465 is an Internet Engineering Taskforce document published in Feb 2015, which outlines the changes to TLS that should be implemented to remove the use of RC4.
In additional to the 3 requirements listed in the guidance notes from the PCI SSC (highlighted in grey below) there are some additional requirements that involve strong cryptography in the PCI DSS.
|
PCI DSS v3.1 requirement
|
Description
|
|
Requirement 1.1.6
|
Documentation and business justification for use of all services,
protocols, and ports allowed, including documentation of security features
implemented for those protocols considered to be insecure
|
|
Requirement 2.2.3
|
Implement additional security features for any required services,
protocols, or daemons that are considered to be insecure.
|
|
Requirement 2.3
|
Encrypt all non-console administrative access using strong
cryptography.
|
|
Requirement 4.1
|
Use strong cryptography and security protocols to safeguard sensitive
cardholders data during transmission over open, public network
|
|
Requirement 8.2.1
|
Using strong cryptography, render all authentication credentials
(such as passwords/phrases) unreadable during transmission and storage on all
system components.
|
For existing implementations of SSL and early TLS when be audited they would need to include the usage under insecure protocols in requirement 1.1.6 and include a business justification for its usage.
If SSL and early TLS is being used, it should be configured to reduce the risk of being exploited and these additional measures should be covered under requirement 2.2.3
For requirement 2.3 and 2.4 strong TLS should be used, if SSL and early TLS is used they should be a risk mitigation and migration plan in place and the SSL and early TLS should be replaced by 30th June 2016.
Requirement 8.2.1 again strong TLS should be used if not similar controls to those for requirement 2.3 and 2.4 should be in place.
Testing the connection
If a HTTPS based connection is used than the strength of the connection can be determined through a browser. Browser’s these days present security information about the connections, although different browsers do it different ways. With Firefox it is easier to determine the encryption strength as shown in the screenshot below.
With Internet explorer using the menu and file properties the encryption properties of the currently selected tab can be viewed. Additionally the server certificate can be viewed, along with the trust chain.
If you examining the validity period of the Google certificate, you will notice it is only valid between May 6th, 2015 and Aug 4th 2015. Whilst this is a short period it demonstrates a point that security professionals and cryptologists understand is that the more frequent a key is used the increased chances of statistically analysis determining something useful about the key, which will help with break it. With hybrid cryptographic systems such as TLS and SSH, they use the public/private asymmetric encryption to dynamically generate a symmetric secret key for encrypting the data stream used to protect the information exchanged.
The PCI DSS standard v3.1 has a number of requirements involving the life-cycle of cryptographic keys and these will apply to digital certificates as well as any other form of encryption.
|
PCI DSS v3.1 requirement
|
Description
|
|
Requirement 3.5
|
Document and implement procedures to protect keys used to secure
stored cardholder data against disclosure and misuse
|
|
Requirement 3.5.2
|
Store secret and private keys used to encrypt/decrypt cardholder data
in one (or more) in a secure manner at all times
|
|
Requirement 3.5.3
|
Store cryptographic keys in the fewest possible locations.
|
|
Requirement 3.6
|
Fully document and implement all key-management processes and procedures
for cryptographic keys used for encryption of cardholder data, including the
following
|
|
Requirement 3.6.1
|
Generation of strong cryptographic keys
|
|
Requirement 3.6.2
|
Secure cryptographic key distribution
|
|
Requirement 3.6.3
|
Secure cryptographic key storage
|
|
Requirement 3.6.4
|
Cryptographic key changes for keys that have reached the end of their
cryptoperiod (for example, after a defined period of time has passed and/or
after a certain amount of ciphertext has been produced by a given key), as
defined by the associated application vendor or key owner, and based on
industry best practices and guidelines
|
|
Requirement 3.6.5
|
Retirement or replacement (for example, archiving, destruction,
and/or revocation) of keys as deemed necessary when the integrity of the key has
been weakened (for example, departure of an employee with knowledge of a
clear-text key component), or keys are suspected of being compromised.
|
|
Requirement 3.6.6
|
If manual clear-text cryptographic key-management operations are
used, these operations must be managed using split knowledge and dual
control.
|
|
Requirement 3.6.7
|
Prevention of unauthorized substitution of cryptographic keys.
|
|
Requirement 3.6.8
|
Requirement for cryptographic key custodians to formally acknowledge
that they understand and accept their key-custodian responsibilities.
|
To cover the requirements listed above there will need to be suitable policies, procedures, standards, baselines and guidelines in place.
The cryptoperiod for a site with extremely high levels of traffic will have a shorter validity period than one with minimal amount of traffic. NIST produce a guideline on cryptoperiod which is mentioned in the PCI DSS standard.
Certificates can have a defined key usage field that defines the activities the certificate can be used for; it could indicate that the key should be used for signatures but not for encipherment. The correct certificate must in place on the server.
VeriSign and other bodies use classes of certificates to determine the level of authentication they use to verify the identity of the organisation requesting the certificate.
- Class 1 for individuals, intended for email.
- Class 2 for organizations, for which proof of identity is required.
- Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
- Class 4 for online business transactions between companies.
- Class 5 for private organizations or governmental security.
Checking for class 1 is done by simply checking if the requester responds to the email address the certificate is for, this level of checking is not suitable for an ecommerce operation.
Certificates need to be trusted by a recognised certification authority (CA), self-signed certifications, or certification issued by untrustworthy CA should not be used. A certificate trust chain should lead to a certificate from a CA that is recognised by a computer without installing a certificate for the CA.
Within the EU there is an EU Directive 1999/93/EC on "a Community framework for electronic signatures" which defines the term qualified certificate and the requirements an issuer must meet to issue such a certificate.
There are a lots of documents describing best practice for digital or X.509 certificates that are either vendor or platform dependent. The recommendation is to find the relevant best practice for the platform and infrastructure you are operating.
In addition to examining a certificate using the tools within browsers it is possible to download the certificate and use tools such as openSSL to display all the fields of the certificate. The following command is an example of how to output the certificate in a readable form. The certificate will need to be in a suitable form such as .pem or 64base encoded .cer if exported through windows operating system.
OpenSSL> x509 -in google.cer -noout -text
In addition to the certificates installed, a server will support a range of cipher suites that support various combinations of encryption algorithms and key lengths to exchange keys, protect data streams, and provide integrity, non-repudiation functionality.
There are a number of naming conventions in use for cipher suites, the most common format is that based on openSSL naming convention that defines the encryption for the four basic functions of a cipher suite.
- key exchange,
- server certificate authentication,
- stream/block cipher
- message authentication
An example of this would be DHE-RSA-AES256-SHA which breaks down to the following.
- DHE for key exchange,
- RSA for server certificate authentication,
- 256-bit key AES for the stream cipher, and
- SHA for the message authentication.
For PCI DSS compliance the server should only support cipher/key length combination considered to be strong for it to meet the requirements.
When clients connect to servers as part of the negotiation they decide on which ciphers to use and exchange keys. The cipher has to be common on both devices and as an organisation operate a server they generally don’t control of what is installed on clients and have a range of ciphers installed.
As a cryptologist/security professional should understand the negotiation does not go for the strongest cipher as there is considerable computational overhead in strong ciphers and long key lengths but often selects the weakest common denominator. Therefore to force strong cryptography the server should only have strong ciphers installed.
Tools such as Nessus, sslscan, ssltest can list the installed cipher suites and ssltest (operated by Qualys SSL Labs) can give a rating to the security of the server certificate and installed ciphers.
Scanning tools can determine the set-up of SSL/TLS and the features that have been enabled, the exposure to currently known vulnerabilities, the installed ciphers and the preferred ciphers. The output of the tools does need to be interpreted by security professionals who understand cryptography.
Additional testing
For compliance testing there is a need to demonstrate that strong cryptography which renders all authentication credentials (such as passwords/phrases) and card data unreadable during transmission is proved.
As requirement is to ensure that secure channel is created before the information is exchanged the definitive method will be to use a packet sniffer and look at the communication session being created and ensure a secure channel was created and the data is not being transmitted in cleartest.
In order not to affect either the server or client and ensure that the transmitted packets are being monitored, a network tap or the span or mirrored port on a switch can be used to monitor the communication as shown.
The packet sniffer is isolated from the endpoints, it can’t give a false positive by reading packets before they have been encrypted which is a possibility if the packet sniffing software was installed on an endpoint.
The network tap or switch configured to span or mirror a port can be used to monitor the traffic between endpoints, the packet sniffer will pick up all traffic passing over the monitored connection and will need filtering to remove the frames and packets not relevant to the testing.
Using tools such as tcpdump, wireshark and network forensic analysis tools can help an auditor to accurately determine in the connection and the date being transferred is securely encrypted.
Resources
SSL Server Test is a free online service operated by Qualys SSL Labs that performs a deep analysis of the configuration of any SSL web server on the public Internet.
The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS) protocols
SSLScan queries SSL services, such as HTTPS, in order to determine the ciphers that are supported. SSLScan is designed to be easy, lean and fast. The output includes preferred ciphers of the SSL service, the certificate and is in Text and XML formats.
tcpdump, a powerful command-line packet analyzer; and libpcap, a portable C/C++ library for network traffic capture.
Wireshark is a network protocol analyzer for Unix and Windows.
No comments:
Post a Comment