PKI SYSTEMS TEST : Initial Planning and Long-Term Strategy

Susan Congiu

2/01/2001

Version 1

Abstract

A solid PKI supports the following features: Public key encryption to protect packages using digital certificates to encrypt, decrypt; digital signing of packages verify identity and integrity of packages; certificate management using local storage for sender certificates and verifies sender/recipient certificates. This plan is a broad overview and is meant to step out-of-the box and look at your holistic architecture. The common goal is that we want to make sure that for true web security we have privacy, authenticity, integrity, and availability. Furthermore, a solid long-term strategy should be signed off on to ensure that legal aspects can be handled if your server is somehow compromised.

PKI Test Cases and Permutations

1.4  Overview

Before even testing Public Key Infrastructure, we need to look at each of the components of our architecture and have all our pieces in place before starting. Hence: In order to decrypt, we need to encrypt. Moreover, In order to test a public key, we need to have the private key. As you can see, there is a corresponding relationship here and we need to test with a dual role in mind: first by ‘being’ the sender and also by ‘being’ the recipient.

1.5  Test Group Objective

These are the components that you may need to configure:

Desktop Client:

·  Sender searches for the recipient’s certificate in LDAP server and uses that certificate to encrypt package.

·  Sender generates a unique symmetric key that encrypts package with that key

·  Sender uses recipient certificate (with recipient’s public key) to encrypt the symmetric key

·  Sender signs S/MIME package and uploads via SSL to server

·  Recipient uses personal certificate to decrypt the package (may contain digital signature too)

·  Client SSL already configured with Window’s wininet.dll and schannel.dll

Server:

·  Provide authenticity via a list of CA’s and root certificates (supporting Server Gated Cryptography)

·  Provides list of Intermediate CA’s and their certificates

·  Enforces encryption re: embargoed countries do not have RC2 128bit RSA 1024bit

·  You can further limit connections in hosts.allow or hosts.deny file

·  Database stores encrypted RC4 file keys and salt as well as unique one-way SHA-1 hash of passwords. A Salted password is used to decrypt file keys.

Directory Server (LDAP):

·  Relied on by your client as a source of recipient certificates (which cannot be stored locally on user’s system).

·  The LDAP server must be populated with recipient information and assumes the server is searched by email addresses.

·  Due to increased admin of an LDAP Server - Will we need Certificate Revocation Lists (CRL) or the Online Certificate Status Protocol (OCSP) to manage valid certificates?

·  Make sure the LDAP port is enabled

-  Search root? (if used)

-  Will login information be required?

·  Is your Server associated with a particular CA? Intermediate CA?

BROWSER Requirements: To enable Java

It is essential to understand the key differences between Internet Explorer and Netscape.

IN NETSCAPE: Go to Preferences/Advanced:

  1. Enable Java
  2. Enable JavaScript
  3. Enable Smart Update

IN IE: Go to View/Internet Options/Advanced:

  1. Enable Java.
  2. Enable Java JIT Compiler

Authentication Test Cases and Permutations

Authenticate your Server to Client

  1. Verify Trusted Certificates, Informational Certificates, and Directory Servers on the server.
  2. Verify Setup/addresses on your client to verify LDAP server. Go to Setup/Addressing.
  3. Your client should search the LDAP server to verify your certificate information when you apply a digital signature.

Authenticate your Client to Server as the SENDER

  1. Verify Trusted Certificates, Informational Certificates, and Directory Servers on the server.
  2. Each email address should be UNIQUE on your server establishing a unique identity. Passwords are stored in your database using a SHA-1 hash algorithm or similar.
  3. A user should be locked out after 10 unsuccessful login attempts.

Authenticate your Client to Server as the RECIPIENT

1.  Recipient must provide valid private key/personal certificate to decrypt and view package

1.6  Certificate Validation Test Cases and Permutations

Validate Certificates on your Client Machine:

  1. You must import a certificate (.p12 or .pfx) into your client from a valid CA, non-revoked, and non-expired.
  2. Only one can be used at a time for signing and encrypting. You may import more than one however, you must ‘set as default’ which cert it will be.
  3. Change your browser store password as well often. You will be prompted to enter the old password and enter a new password/and confirm password.
  4. Check certificate effective and expiration dates. Browsers do not do this automatically.
  5. Check algorithm the certificate uses. Certificate must contain an RSA (BSAFE 3.0) public key- (RC2 symmetric key algorithm)
  6. Verify file key max RC2 size: 128 bit and max RSA key size: 1024 bit.
  7. Check Country for encryption strength
  8. Check Serial Number
  9. Check Thumbprint (verifies it came from the specific CA such as Verisign). May appear invalid if problems connecting to server.
  10. Validate embargoed country strength is set to zero bits and the sender is alerted. Should change security to one that does not contain S/MIME.
  11. Validate email address contained exactly in cert and match address for the person’s email account accessing your server remotely.
  12. Verify intended use (Key Usage) of what the certificate authorizes: digital signing, encryption or both.
  13. Verify the certificate can be deleted. It should only be deleted you’re your Browser Certificate Store and not your hard drive.

Validate Secure Packaging (S/MIME v2 protocol) Integrity Tests:

  1. Verify Recipient Certificates (including public key) are in your Browser Certificate Store.
  2. If successful, signing should be performed using your default private key AND/OR recipient’s public keys
  3. Private keys are stored in Registry in the PKCS 12 format using Triple DES encryption
  4. Verify that password is required to sign/encrypt packages
  5. Verify that password is required to manipulate private key storage
  6. Verify that password is required to change the password.
  7. Verify if you have multiple private keys that you have a default selected.
  8. Verify sender info: sender should always be able to decrypt message.
  9. Issuer of certificate must be in Certificate Chain among the trusted CA’s (verifies both sender and recipient certificates).
  10. Verify directory server includes a valid certificate(s) or it should fail.
  11. Verify that the certificate listed is one of your approved LDAP servers in your Security Policy and Procedures. Review these and be proactive.
  12. Is the checking of the revoking of certificates performed by an LDAP admin?
  13. Repeat for each recipient (all or nothing)- should fail if encryption not allowed. Sender then can either cancel or use weakest encryption.
  14. Public Key Encryption uses a corresponding pair of keys- a private to encrypt and a public to decrypt. Make sure they only correspond to each other.
  15. Sender should encrypt data with recipient’s public key so only the intended recipients can decrypt. Include yourself as a recipient when sending so you can decrypt the package.
  16. Validate recipient decrypts with their private key.

1.7  Certificate Integrity Test Cases and Permutations

  1. Retrieve secure package via browser
  2. Check for recipient certificate and private key (if encrypted) –must be imported into your Browser Certificate Manager.
  3. Validate the package can be downloaded
  4. As a recipient, decrypt message using private key (PKCS #12 format) in your certificate manager store or import it. The newly generated message digest (or digital signature) is compared to the decrypted message digest. Both should be identical (and that your signature is valid). Recipient’s private key matches public key to encrypt the message.
  5. The digital signature is signed with the sender’s private key with the PKCS#7 format.
  6. If digital signature is not valid, then the recipient should get an error and not be able to access the message’s contents.
  7. As Receiver, validate that all matching keys can be found except LDAP verification (sender).
  8. If terminating an applet – check that files are deleted from local storage

Whew – what a busy test cycle- ready to do it all over again? We’ve done some extensive testing from both the role as a sender and as a recipient. Now that we know our PKI is functioning (and this of course can vary according to your spec), let’s ensure that we are always thinking long term and proactively.

What’s interesting about this paper is that we are not only a dual-role in the testing but in the planning as well. First, we have to gather materials, digital id’s, and ensure we have a secure web architecture. Getting into scalability and fail-safe measures of course is a whole other topic. The focus here is not only the initial planning, but the long-term strategy! Are you properly prepared if there will be any potential legal issues? Is your ever-changing environment and requirements being documented and adhered to? Below is a checklist as a starter for your more long term planning needs that should be addressed in your organization.

Common organizational mistakes are to develop a product, have the typical feature-creep and date slippage, and then lo-and-behold, you have 3 weeks to test! Well, beyond functional and regression test to ensure proper flows, we need to assess how our business model itself will scale and be legal, competitive, and fit within budget. Sound impossible? Sure- it’s a challenge and that’s why the world of PKI appears so complex! This paper breaks down the components step by step and is meant as a guide. Remember what may initially seem rigid in your test planning and long term strategy, will only make your rate of discovery of defects and overhead rate in your budget less costly!

1.8  PKI objectives for long term planning to consider :

·  Will you be your own Certificate Authority or will you be only the intermediate CA?

·  If you are your own CA, will there be an LDAP admin to maintain the Certificate Revocation Lists (CRL)'s and monitor OCSP? Do people on your team know what they own and are they familiar with their job responsibilities? Is there coverage if that person is absent?

·  Who will draft a policy for usage and maintenance?

·  What is the optimal expiration (policy question again) for end-user certificates?

·  What is the projected LOAD on the CA, RA, and LDAP servers in 3 months, how about 6 mos., 1 year, 2 year......

·  How will our current infrastructure scale?

·  Who sets the access control limits and capabilities?

·  In your Policy, there should be a procedure for revocation of admin privileges in case the admin leaves (security risk). In this market, turnover happens more frequently than we’d like.

·  Remember morale- ‘thank you’ is never over-used.

·  A concise, tested contingency plan is a necessity if anything is compromised.

·  A data backup policy and disaster recovery plan is a must!

·  In Production, will your Legal Department need to get involved? Define what is an 'acceptable' digital signature? It is possible in a Court of Law that someone could claim, “I repeat. I did not have an ‘unacceptable’ relationship with that server!” or “I did not compromise it’s private key”.

·  Are you liable if a customer repudiates?

·  What about if you misuse keys – are you liable?