Guidelines for Developing eID-Enabled Applications: Testing and Validation Best Practices

1. Guidelines for developing eID enabled applicationsWim Coulier – Senior Project Manager PKI24/06/2004

2. Topics • Existing testing environment • Prevent errors • What to test?

3. Self-signed GlobalSign TOProot CA Self-signed Common Key Pair Belgium SelfSignedRoot CA Belgium RootSignedRoot CA Admin CA Government CA Citizen CA Signing Cert. SSL Cert. Auth. Cert. Obj. Sign Cert. Role Cert. Test Infrastructure • Complete test infrastructure equivalent to eID production infrastructure created by Certipost

4. Test Cards • Certipost and Zetes offer eID test cards • See http://www.eid-shop.be for current prices and ordering • Realistic card data • All data fields present • Same data protection applied as for production certificate (e.g. test RRN certificate, etc.) • Remark: test RRN certificate will now also be in the complete chain

5. Test Cards • Certificates created from full PKI test infrastructure • Citizen certificates with complete chain (Belgium Citizen CA – Belgium Selfsigned Root CA / Belgium Rootsigned Root CA) • Certificates with Valid, Suspended, Expired and Revoked status for proper testing • Both signing and authentication certificates • The certificates refer to the existing test validation points (CRL and OCSP)

6. Certificate validation • OCSP – CRL servers: provided by eID • Pro and cons CRLs vs OCSP: • CRLs check can be local • CRLs download is heavy vs OCSP use • CRLs security level is lower • OCSP client: integration in applications often to be done • PKI libraries: integration in applications

7. Certificate validation • CRL (Certificate Revocation List) • Manual retrieval of the CRL (http://status.eid.belgium.be/crl/) • Automated manner: the CA will publish each 3 hours a new CRL (valid for 7 days) -CRL (valid for 3 hours) on http://crl.eid.belgium.be/ • Standard CRL validation in MS via CryptoAPI

8. Certificate validation • OCSP (Online Certificate Status Protocol) • This protocol allows the applications to verify on-line the status of a certificate in real time at http://ocsp.eid.belgium.be/ • Technical details see RFC 2560

9. Certificate validation • Example OCSPrequest: Requestlist Request CertID HashAlgorythm: sha1 issuerNameHash: 3F 52 BA A6 31 56 18 68 17 F6 31 C8 11 2F 21 43 F6 C4 99 43 issuerKeyHash: 13 50 2C A9 03 99 5A 14 CF 0F B0 7B 08 AD 53 AD 5B 39 E5 1F serialNumber: 1208925819615706400000000 RequestExtensions Object Identiefer: id-pkix-ocsp-nonce Nonce: 33 34 2F 6A 9E C1 10 D0 52 E4 4F 5F 7E FF D9 80 7B 4F BC C1

10. Certificate validation • Example eID OCSPresponse: Responsestatus: Successful responseType: id-pkix-ocsp-basic BasicOCSPresponse ResponseData ProducedAt: 20040621093607Z Responses CertID: Same as Request Certstatus: Good (vs. Revoked or Unknown) ThisUpdate: 20040621093607Z ResponseExtensions Object Identifier: id-pkix-ocsp-nonce Nonce: 33 34 2F 6A 9E C1 10 D0 52 E4 4F 5F 7E FF D9 80 7B 4F BC C1 SignatureAlgorythmIdentifier: sha1withRSAEncryption Signature: BIT STRING Certs Sequence of certificates: Belgium OCSP Responder – Citizen CA – Belgium RootCA

11. Test Validation services • Manual a certificates status validation: http://status.specimen-eid.belgium.be • Test CA certificates retrieval: http://certs.specimen-eid.belgium.be/ • CRL retrieval: http://crl.specimen-eid.belgium.be/ • Test OCSP (requires OCSP client): http://ocsp.specimen-eid.belgium.be/

12. Prevent errors • Look for exceptions • Do not make assumptions on data characteristics e.g.: • Presence of given name: people without one exist • One “word” is one name: e.g. “Chang Lu” is the first given name (not Chang first given name and Lu second given name) • Hardcoding of references (e.g. OID, CA certificate, CRL distribution point, OCSP reference, …) GET IT DYNAMICALLY FROM THE CERTIFICATE!

13. Prevent fake data attack • Risk: cracker uses a real certificate for authentication, but uses real data (e.g. address, photo) from other person to feed remote capture • Solution • Data is signed, signature can be verified • Sure about 1 piece of info => sure about all info • Validate RRN no from remote capture with RRN number in authentication certificate used => positive match = certainty remote captured data belongs to person that authenticated himself

14. What to test: data capture • Verification on modified data: Sign data with own certificate and feed directly to your code during unit testing • Testing for fake signatures: generate signature on data with fake certificate and feed directly to your code during unit testing • Verifying signed data = verifying signature certificate => see certificate validation

15. What to test: Certificate validation • Certificate expiration date • Certificate validity (CRL or OCSP) • Certificate chain: • Citizen CA: check expiration date and validity • Belgium Root CA: check expiration date • Belgium Root CA in Trust List => remove in case of breach

16. Testing tips • Test during coding with Test cards • After coding test with a production card • Add production Belgium Root CA to Trust List • Check on dynamic retrieval of references and certificate chain from the certificates • Makes not really a difference for the status validation • Make sure that before going to production the test Root CA is NOT trusted anymore

17. Questions? See you at www.certipost.be/eID