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

2  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 SAFE Goals

3 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 What Technology Does the SAFE Credential Employ?

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

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

6  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 Who Issues SAFE Credentials?

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

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

9  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 How Does a User Get a SAFE Credential?

10  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 What is a Bridge Certification Authority?

11  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) Is it Hard to Establish a Bridge CA?

12  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 What does SAFE Mean to Users?

13  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 For Vendors

14 Discussion

15 Back-Up Materials

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

17 Applications need to be SAFE Enabled

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

19 Issuer AIssuer B User A AppUser B App Bridge CA CRL Publishing Issuer AIssuer B User A App User B App b Bridge CA CRL Publishing Issuer AIssuer B User A AppUser B App Bridge CA CRL Publishing Recommend for SAFE Phase 1 developmentRecommend on-hold for subsequent SAFE Phase development SAFE Signature Verification Options

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

21 Issuer AIssuer B User A AppUser B App 1. User A sends signed message to relying party B 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) 3. Issuer A validated User B certificate 4. Sends timestamped signed response validating user B Signature Verification Option 2: Member Performed 1b. User B validates that Issuer A is contractually bound into the system Bridge CA CRL Publishing Recommend on-hold for subsequent SAFE Phase development SAFE Signature Verification Option 2: Member Performed

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