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
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.
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 oneway 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
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.
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!
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?