June 16 2004 Richard Guida Stephanie Evans

1. SAFE Infrastructure Overview June 16 2004 Richard Guida Stephanie Evans Johnson & Johnson Johnson & Johnson Director, WWIS WWIS

2. SAFE Goals • A single electronic credential which: • Can be used and accepted across multiple organizations • Allows legally binding electronic signatures to be made in countries around the world • Is easy and straightforward for the user to employ • Can be obtained from a SAFE-accredited source of the user’s choice • Vendors will have the opportunity to pursue SAFE-accreditation • No single supplier controls the marketplace • A set of open standards covering: • Software that can make, and validate (check), electronic (digital) signatures meeting SAFE business rules • Ultimately, this capability built in to off-the-shelf products • A trust-based, collaborative community of biopharmaceutical companies and their business/regulatory partners efficiently using electronic processes to conduct business transactions

3. What Technology Does the SAFE Credential Employ? What Technology Does the SAFE Credential Employ? Public Key Technology • Widely used for secure electronic and internet transactions today • Based on two keys (large numbers), mathematically linked • One key is kept private, the other is made public • Public key appears in a digital certificate – an electronic credential (file) that links the public key to a person’s identity • Private key is kept secret on a hardware device (like a smartcard) • To make a digital signature, the user of the hardware device inserts it into the PC and proves his or her identity to the device (usually done with a passphrase that only the user and the device knows). • The private key on the device then makes the digital signature on the document selected by the user. • To validate (check) a digital signature, commercially available software uses the public key from the digital certificate

4. 3. Present information (message) to be signed to the user (signer) • Authenticate [best practice] • Select information to be signed 4. Select Signature parameters Private Key Data object Sign Hash SAFE Transaction Meaning of signing: Approved Certificate S S Digital Signature Certificate Subscriber PKCS #7/CMS 5. Acknowledge the signature parameters (request for biometric/passphrase/password and legally binding message) 7. Log transaction The Signing Process 6. Create the digital signature (preserves document integrity)

5. 2. Certificate Validation and Digital Signature Verification 3. Acknowledge verification and validation Hash • Receives signed message Yes = valid No = invalid Equal? Document (as received) Hash S Public Key OCSP Validate Relying party OCSP Trusted Root CA OCSP Intermediate CA Log OCSP response Subscribers Signature Verification Process 4. Log transaction

6. Who Issues SAFE Credentials? • A special server called a Certification Authority (CA) • Analogy: the machine at the Department of Motor Vehicles which creates your driver’s license • But only after you have proven your identity to a Registration Authority (RA) • Analogy: the window at the DMV where you prove who you are before you can get your driver’s license • An “Issuer” is a vendor, bank, or company that operates a CA and an RA, and issues/supplies credentials to users • SAFE will accredit Issuers so that users wishing to get SAFE credentials (digital certificates) can trust who supplies them

7. Pharma 2 Pharma 3 Global Trust Challenge EMEA CRO 1 Pharma 1 FDA CRO 2 MHLW Tradepartner 1 MS3 MS4 Tradepartner 2 MS5 The Biopharmaceutical Industry has many communication partners.

8. = Pharma Outsourced Identity Credential Provisioning Issuers Regulated Financial Institutions The Solution: SAFE Trust Bridge Individual Trust Domains Syndicated Bank Trust Network = Pharma X BioPharma Industry Trust “Bridge” = = Biopharma Y = = FDA j = EMEA Any SAFE Accredited CA

9. How Does a User Get a SAFE Credential? • Two possibilities: • Your organization has its own internal or out-sourced CA which can be cross-certified with the SAFE Bridge CA • Your CA issues your employees SAFE-compliant credentials (certificates) which can then be accepted by other SAFE Members using the SAFE Bridge CA • You purchase a SAFE credential (certificate) from a SAFE-accredited Issuer that is cross-certified with the SAFE Bridge • Either way, your credential is interoperable and accepted within the SAFE community

10. What is a Bridge Certification Authority? • A CA which establishes “trust connections” among other CAs • Issues certificates to SAFE “Member” CAs • Accepts certificates issued to it by SAFE “Member” CAs • (Analogy: mechanism to permit one DMV to trust drivers’ licenses issued by another DMV – electronically) • Is NOT a “root of trust” – rather, just a conduit of trust • Employs a distributed - NOT a hierarchical – model • Thus, all members are treated as equals • Is product-neutral – employs open standards for certificate issuance and management • Will support digitally signed transactions among Members, and between Members and regulators

11. Is it Hard to Establish a Bridge CA? • No – in fact, there is one already in operation (the U.S. Federal Bridge CA) and several others in the planning stages • What is needed is: • A Certification Authority • Policy foundation • Certificate Policy per RFC 2527/3647 • Certification Practices Statement per above • Hardware • Server running CA software • Server running directory/data base software • Server running software to respond to inquiries on certificate status • A governing body (typically called a Policy Authority) • An operational body that actually runs it (typically called an Operational Authority)

12. What does SAFE Mean to Users? • One hardware device per person, which holds your digital identity (this identity cannot be copied) • Ability to make your electronic (“digital”) signature on a document or transaction, meeting SAFE rules so it is legally binding • Ability of any SAFE Member to check (“verify”) your signature

13. For Vendors • There is plenty of software currently available which performs and validates digital signatures. Two examples (there are many others): • Adobe 6.0 • Microsoft Office XP/2003 • We are releasing standards for SAFE-compliant signing and validation software • We encourage vendors to adjust their products to meet these standards • In most cases, doing so should not require substantial changes to existing products

14. Discussion

15. Back-Up Materials

16. Use of Industry Standards SAFE incorporates the STANDARDS from • Internet Engineering Task Force (IETF) RFCs • Federal Information Processing Standards (FIPS) • RSA PKCS

17. Applications need to be SAFE Enabled

18. Certification Authority Cross Certificate End Entity Certificate SAFE Bridge CA B Relying parties are colored the same as their trust anchor.

19. CRL Publishing CRL Publishing Bridge CA CRL Publishing CRL Publishing Bridge CA 3 Issuer A Issuer B 4 4 Issuer A Issuer B 5 3 1b 5 2 2 1 User B App User A App 1 User A App User B App CRL Publishing CRL Publishing Bridge CA 3 Issuer A Issuer B 2 1 User A App User B App SAFE Signature Verification Options Recommend for SAFE Phase 1 development Recommend on-hold for subsequent SAFE Phase development Recommend on-hold for subsequent SAFE Phase development

20. SAFE Signature Verification Option 1: Issuer Performed Signature Verification Option 1: Issuer Performed CRL Publishing CRL Publishing Bridge CA 4. Sends a timestamp signed response informing User B certificate is valid Issuer A Issuer B 3. Issuer B request for validation of User A certificate 5. Informs user B certificate is valid 2. User B validates certificate of User A by sending a signed request to it’s Issuer (CA) User A App User B App 1. User A sends signed message to relying party B Recommend for SAFE Phase 1 development

21. Signature Verification Option 2: Member Performed SAFE Signature Verification Option 2: Member Performed CRL Publishing CRL Publishing Bridge CA 3. Issuer A validated User B certificate Issuer A Issuer B 4. Sends timestamped signed response validating user B 1b. User B validates that Issuer A is contractually bound into the system 5. Sends timestamped signed response informing User B certificate is valid 2. User B validates certificate of User A by sending a signed request to it’s Issuer (CA) User A App User B App 1. User A sends signed message to relying party B Recommend on-hold for subsequent SAFE Phase development

22. SAFE Signature Verification Option 3: SAFE Entity Performed Signature Verification Option 3: SAFE Entity Performed CRL Publishing CRL Publishing Bridge CA 3. SAFE informs user B that certificate is valid based on current SAFE & Issuer CRLs Issuer A Issuer B 2. User B validates certificate of User A by sending a signed request to SAFE Bridge CA User A App User B App 1. User A sends signed message to relying party B Recommend on-hold for subsequent SAFE Phase development