Overview of Technologies Supporting Security Requirements in 21 CFR Part 11 Part II

Part I of this article, which was published in the March issue of 21 CFR Part 11: Compliance and Beyond, discussed current technologies that can be used to manage the security associated with regulatory-related electronic records. Part II reviews how electronic-based solutions can be designed to conform to the security-related requirements in 21 CFR Part 11.

The goal of an enterprise public-key infrastructure (PKI) is to protect information assets through electronic-based solutions that comprise hash algorithms, data encryption, digital certificates, message digests, digital signatures and audit logs. The key condition and solution critical to 21 CFR Part 11 are authentication and encryption, respectively. Authentication verifies a person's identity as well as the integrity of records. Encryption protects the privacy of records. Although most information transactions do not require this level of comprehensive digital trust, PKI is the best choice for ensuring compliance with Part 11 security requirements and consequently for ensuring the privacy of records.

All electronic-based solutions should be implemented by first evaluating the security infrastructure and a user's needs. This evaluation should include analysis of the security infrastructure, maintenance, and the system's potential growth. Table I summarizes the security-related Part 11 requirements. The following is a summary of how electronic-based solutions (technological controls) may be integrated to support Part 11.

Protection of records. All operations with records should be performed in a secure environment. This requirement applies to

• records with or without signatures

• records in transit.

Organizations can use access controls, encryption (for example, end-to-end data encryption) and hashing to protect the integrity, authentication and privacy of records, and to prevent their loss. For example, records must be protected when confidential patient data are sent to other locations. Access controls are discussed later in this article.

Encryption. Encryption can be used to protect records in transit between networks, including the Internet. Tools such as network diagnostics or protocol analysers can read information easily as it is transmitted. To alleviate this problem, systems such as secure sockets layer (SSL), transport layer security, or virtual private networks (VPNs) can provide the necessary management of critical data across networks. These solutions use encryption, digital signatures or digital certificates to ensure data privacy, identification of the originator of messages and verification of message integrity.

Table I Part 11 security-related requirements and controls.*

End-to-end data encryption with PKI technology is implemented by encrypting messages and records with a recipient's public key, thus rendering messages and records unreadable to anyone except that recipient. To encrypt messages and records, the certification authority (CA) issues distinctive digital signing certificates containing the public key assigned to a recipient. Messages and records can be decrypted only with a recipient's private key. The combination of hashing and access controls provides another opportunity to protect sensitive records.

One alternative to sending messages and records via the Internet is through the use of Secure/Multipurpose Internet Mail Extensions (S/MIME), which is the standard for secure e-mail within PKI. It enables secure communication between two or more parties by ensuring the integrity and authenticity of a message that is given a digital signature and the confidentiality of a message if it is encrypted.

Scheduled backups, restoration procedures, and off-site storage of media are the best practices for supporting the recovery of records. The metadata (data that describe the structure, elements, interrelationships and other characteristics of electronic records) associated with each record should also be saved. On the basis of archival requirements, the protection of records includes the consideration of the degradation rate of the electronic images and the availability of the devices and software needed to access all records.

Access controls. Public-key certificates can be used to authenticate the identity of a user, and this identity can be used as an input to access-control decision functions. Access-control decision functions are defined through access rights lists, for example, access control lists (ACLs) with functions such as use, read, write, execute, delete, or create privileges. In Microsoft Windows 2000 (Microsoft Corporation; Redmond, Washington, USA), an ACL is a list of security protections that apply to an entire object, a set of the object's properties or an individual property of an object. Each active directory object has two associated ACLs: the discretionary access control list (DACL) and the system access control list (SACL). A DACL is a list of user accounts, groups and computers that are allowed (or denied) access to the object. A DACL is a list of access-control entries (ACEs) in which each ACE lists the permissions granted or denied to the users, groups or computers listed in the DACL. An ACE contains a security identification with a permission statement such as read access, write access or full control access. The SACL defines which events (such as file access) are audited for a user or group.

Access controls provide the means to design a system in such a way that, for example, a supervisor can access information belonging to a group of employees without allowing everyone else on the network to access it too. In the context of Part 11, access controls are deemed an element of authority checks.

Authentication. The importance of authentication can be expressed through the following two examples. First, IPSec servers, which are key elements in secure networks, provide the ability to protect traffic between hosts and sets of hosts within the network and check hosts on other networks. The security of an IPSec server depends on strict access controls, authentication, device checks and authority checks. Only specifically identified administrators should be able to log in to the IPSec server or change its configuration. The IPSec server should maintain an audit trail for all computer-related administrator actions. Second, to secure the exchange and integrity of records and messages, both sides - users and processes - must have their identity verified before the exchange occurs. Authentication can be implemented in varying degrees of strength, and it lays a foundation for other security services such as access controls.

In terms of the authentication of a user or of records and messages, first a person typically enters their identification code (user ID) into the system and then authenticates their identity by providing a second piece of information that can be produced only by the person (password). There are three authentication methods: user ID and static passwords; user ID and dynamic passwords; and biometric devices.

User IDs and static passwords. Static passwords are still the cheapest, most widely used simple authentication mechanism. Although one could use stronger mechanisms than passwords (for example, one-time passwords, challenge-response mechanisms, cryptographic mechanisms, or even biometric mechanisms) to accomplish user authentication, passwords are the most common authentication mechanism and often provide adequate protection of computer resources.

Figure 1 SSL 3.0 protocol encrypts data between the server and the browser. It also supports client authentication for access control. (Figure provided by D. Coclin, "Public Key Technology Overview," courtesy of Baltimore Technologies www.baltimore.com).

Currently, most systems offer at least basic password management features. Such features could include

• password aging and expiration, which allows the password to have a lifetime, after which it expires and must be changed

• password history, which checks the new password to ensure that a password is not reused for the specified amount of time or the specified number of password changes

• account locking, which allows automatic locking of an account when a person fails to log into the system in the specified number of attempts

• password complexity verification, which checks the complexity of the password to verify that it provides reasonable protection against intruders who might try to break into the system by guessing the password.

User IDs and dynamic passwords. Passwords and personal identification numbers (PINs), which are alphanumeric codes or passwords used to authenticate an identity, can provide a stronger means of authentication when they are combined with other authentication techniques. Typically, the combination involves something the person knows (for example, passwords and PINs) and something the person possesses, such as tokens. Tokens are software or hardware mechanisms that provide a person with the second piece of authenticating information. Included within this group of mechanisms are

One-time password generators. As the name implies, one-time passwords are similar to traditional passwords because they are used in conjunction with a user ID, but they are limited to one-time use. The advantage of this technique is that it prevents the repetition of a compromised password. Frequently, one-time passwords are used not only in conjunction with user IDs, but also with passwords or PINs. Commonly, a small hand-held device the size of a credit card is synchronized with the target system's authentication scheme and displays a one-time password that periodically changes. To access the target system, the person enters an assigned user ID and password followed by the one-time password currently displayed on the hand-held device. This method of authentication provides additional security because the person must know the information and possess the authentication token.

Challenge-response schemes. These schemes look like one-time password generators and use a similar synchronization mechanism; however, additional user actions are required for authentication. This feature is a challenge-response exchange with a new key that is used at each log-in.

Certificate-based authentication. This feature is an increasingly popular technique for strong authentication. A party wishing to be authenticated presents a digital signing certificate. If the certified party is still trusted in the organization, then the server trusts that the party is who they claim to be. One benefit of certificate-based authentication is that the entity does not need to have an established relationship with, for example, a server before being authenticated. This attribute makes certificate-based authentication an excellent solution for online commerce.

SSL 3.0 protocol (Figure 1) uses X.509v3-compliant digital certificates for authentication. The most common use of SSL is to authenticate a server to a person, but it can also be used to authenticate a person to a server. By authenticating a server, the person is assured communication with the correct site. SSL also signs the transmitted information so the person is assured that the information has not been changed during transit.

Another example of certificate-based authentication is the authentication of e-mail transport. E-mail transport can be checked against the identity of the recipient through authentication technology. Authenticating e-mail users ensures there is no fraudulent user access. Smartcards and tokens are also common methods to implement dynamic passwords and certificate-based authentication.

Biometric devices. Biometric mechanisms tend to be best suited to the enforcement of physical access rather than electronic access; that is, they do well where a human guard (or proximity sensor) might be used, but they generally do not apply to electronic access to a website. Consider that the biometric in question, for example, your fingerprint is to be used for access to a website. The attacker must capture a person's fingerprint data only once and then can replay it while masquerading as that person. The TruSecure website provides a list of biometric devices ( http://csrc.nist.gov/publications/nistpubs/800-7/node55.html).

The most common methods of strong authentication are automatic password generators, for example, tokens and smartcards. Tokens and smartcards store information regarding a person and require a reader device. To protect against theft, a person must enter a password or PIN before this information in the token or smartcard can be accessed.

Kerberos ( www.isi.edu/gost/info/Kerberos/) is an industry-standard authentication system suitable for distributed computing by means of a public network. Implemented in Windows 2000, it uses public-key encryption and hashing algorithms. Kerberos requires a certificate server that acts as a CA, managing keys and digital certificates. (A server is a computer or device on a network that manages network resources. A certificate server manages key and digital certificates.) This server maintains a database of secret keys for each entity, authenticates the identity of an entity that wishes to access network resources and generates the session's keys when two entities wish to communicate securely.

Records must remain complete during transmission. The unauthorized manipulation of records, audit trail records and replay of transmissions will be reliably identified as errors. Records and messages authentication provides the means to evaluate the integrity of the data and message. It involves technical controls to detect unauthorized modifications to data and messages. A recipient can use three approaches to authenticate data and messages:

• encrypt records or messages using the recipient's public key

• sign the records or message

• use a session key.

Audit-trail controls. As part of the reliability of records, audit trails refer to a journal that records modifications to the records. The person or automated processes operating on the user's behalf may perform these modifications. An audit-trail mechanism provides the capability to reconstruct the modified data and, therefore, does not obscure previously recorded data. The tracking mechanism includes a computer-generated time-stamp that indicates the time of the entry. Audit trails are computer generated and can be part of a record or a record by itself. The date and time of an audit trail should be synchronized to a trusted date-time service.

Controls to the audit trails include record-audit linkage. Audit trails cannot be modified and access to them will be limited to print-read only. The combination of authentication, digital certificates, encryption and ACLs provides the mechanisms to control the access to audit-trail files.

Computer systems time controls. Time-stamping is recognized as a valuable service that supports non-repudiation of transactions. It adds integrity and trust to messages and records sent by means of a network. Accordingly, unauthorized modifications to the system clock and time drift between servers are prevented. Time drift is when two or more servers do not have identical times. The discrepancy can vary from seconds to minutes and can become extensive if left unchecked. The certificate server and client clocks must remain synchronized as closely as possible. The Kerberos-recommended maximum tolerance settings for computer clock synchronization is 5 min. Kerberos uses time-stamps to determine the validity of entities' authentication requests and to help prevent replay attacks.

Part 11 requires that the system date and time are included as part of the audit trials and electronic signatures. The digital time-stamping service (DTS) issues a secure time-stamp - which includes the time, a hash of the digital information being time-stamped, and a time certification - that can be used for digital signatures. A message digest is produced from the record and sent to the DTS, which returns the time-stamp, as well as the date and time the time-stamp was received, with a secure signature. The signature proves that the document existed on the stated date. The document contents remain unknown to the DTS - only the digest is known. The DTS must use lengthy keys because the time-stamp may be required for many years.

DTS and digital certificates provide the mechanism to authenticate the source (device checks) of the time-stamp in the audit trails and electronic signatures. Access-right lists and digital certificates can be used to control access to the DTS.

In addition to DTS, other supporting time controls include an infrastructure that supports time-stamping from a trusted time such as the co-ordinated universal time (www.datum.com/tt). This technology, which in some cases is compliant with X.509 or the Internet Engineering Task Force, is tied into a time-calibration service. Applications or computer logs may require time-stamping services on the server.

Authority checks. Authority checks ensure the correct right-of-entry to records or computer resources and can be implemented by combining ACLs and digital certificates. In one possible scenario, the person accessing a system tries to read and sign a batch record. Before executing these actions, the system verifies the access rights and the validity of the digital certificate to determine if the person is authorized to perform these operations.

In another scenario, an operator logs into the system to perform an operation in a process area. After the operator types the user ID and password, a digital ticket is created that asks the training system to verify the operator's training record and confirm whether the area and equipment were cleaned and released for production. The system returns the appropriate authorization to perform the operation. In this example, authentication, digital certificates and access-right lists are combined to provide the necessary control to operations.

Device checks. Part 11 defines device checks as a means to determine, as appropriate, the authentication of a server and the validity of the source of data or operational instruction. Digital certificates can be used to implement any of these verifications.

Device checks, integrated with PKI, can be used to record and sign electronic case-report forms (e-CRFs). Using, for example, smartcards or tokens, each investigator or investigator's trial staff can log remotely into the external Web server and complete the information required by the clinical-trial protocol. Each smartcard or token can be used to identify each investigator or investigator's trial staff. Only authorized personnel are allowed access to each form. The granularity in an e-CRF can be set to each field in the form. With certificate-based authentication, the communication to the external Web server is secure. Internet Explorer, for example, uses X.509v3-compliant digital certificates to verify the identity of a person, organization, account or site.

Technical controls to open systems. Hashing, encryption, digital signatures and cryptographic product-services families offer the right solutions to open systems as defined by Part 11. These technologies retain a high degree of information security even for information sent by means of open, insecure, but inexpensive and widely used channels.

Signature-record linking. An electronic-signature solution must secure electronic signatures through encrypted copy protection and make it impossible to copy, cut or paste signatures and audit trails from an approved record. This requirement helps accomplish the integrity of digitally signed records. One must consider the integrity and security of the main components of digital signatures: the PKI components. The extent to which the user is confident about the linkage between a public key and its owner depends greatly on the user's confidence regarding the system that issued the certificate that links them.

In addition to the system issuing digital certificates, access-control technologies and procedures, the signature-record linkage must have supporting tools to verify the integrity of this link. PKI uses hashing algorithm and keys to demonstrate the integrity of signed records. A digital signature is linked to a record by incorporating an encrypted message digest of the record into the signature itself. This link is retained for as long as the record is kept and provides the trustworthiness of electronically signed records for that period of time.

For those systems that include user IDs and passwords as electronic signatures, the current level of technology makes it very difficult to implement the signature-records linkage established in Part 11 Section 70. In many of these cases, the electronic signatures are based on software locks. Presently, no technology exists to reproduce evidence of the integrity of a signatures-records linkage and the identity of the signatory when records are signed through user ID and password. Consequently, the trustworthiness of signed records might be compromised. Accordingly, compliance with the following requirement from Part 11 Sections 11.200(a)(2), 11.200(a)(3) and 11.300(d) cannot be ensured: "The combination of authentication schemes such as passwords, biometrics, physical-feature authentication, behavioural actions and token-based authentication, with cryptographic techniques shall be considered to ensure the authenticity of the signatures/records linkage."

Uniqueness of electronic signatures. The main element for signing records and messages in the digital signature is the private key. Users of PKI may generate key pairs. When generated by PKI, key pairs are produced by prime numbers, which are created from large, random numbers (for example, candidate prime numbers). ANSI X9.17 specifies a key generation technique. A private key is uniquely associated with an entity and is not made public.

No matter who generates the key pairs, the CA certifies the public key; however, many organizations mandate that the CA generate the key pair to ensure the keys' quality. In a certificate-based authentication scheme, a browser generates a session key that is encrypted with a server's public key. Session keys are also derived from random numbers.

Electronic-signatures security. Part 11 incorporates requirements for the uniqueness of signatures, authentication, periodic reviews, security and loss management. With digital signature implementations, the integrity and security of the PKI components must be considered. The degree of confidence in the linkage between a public key and its owner depends on the confidence in the CA that issues the digital certificate. Within the cryptographic module (the part of a system or application that provides cryptographic services such as encryption, authentication or electronic signature generation and verification) public keys shall be protected against unauthorized modification and substitution. Private keys and certification practice statements (that is, critical security parameters, which is security-related information such as secret and private cryptographic keys and authentication data such as passwords and PINs whose disclosure or modification can compromise the security of a cryptographic module) shall also be protected from unauthorized disclosure, modification and substitution.

Provisions in X.509v3-compliant digital certificates enable the identification of policies that indicate the strength of the mechanisms used as well as the criteria for certificate handling. The rules expressed by certificate policies are reflected in cryptographic service providers (CSPs) that detail the operational rules and system features of CAs and other PKI components. Logical security and proper configuration to the CA, certificate server and security server help ensure security during the creation and management of digital certificates.

The private key may be stored in a user's local disk in an encrypted format or as part of a token that interfaces with the computer. Personal cryptographic tokens have long been considered to be the obvious secure repository for private keys and the options for on-board cryptographic processing ensure that a private key is never clear outside of the token. As required by Part 11, tokens shall be tested periodically to ensure that they "function properly and have not been altered in an unauthorized manner."

Qualification

Adequate testing of the cryptographic module against established standards is essential for implementation and security assurance. Without adequate testing, weaknesses such as poor design, weak algorithms or incorrect implementation of the cryptographic module can result in insecure security infrastructure technologies.

Following the recommendations of the good automated manufacturing practice (GAMP) guideline,1 a method to record and qualify the configuration of the security infrastructure can consist of

• recording the software name and version

• recording the hardware installation and associated documentation

• performing an impact analysis of security infrastructure to the new, amended or removed features on end applications

• verifying the functionality of the security infrastructure

• testing software and hardware, which includes formal retesting of all networked end applications, including, if applicable, interoperability and conformance to the X.509 certifications path

• executing power-up and conditional self-tests to ensure that the cryptographic module is functioning properly.

Verifying the functionality of cryptographic modules can be achieved by executing a set of tests available from independent and accredited testing laboratories. In the majority of cases, developers of cryptographic modules use these laboratories to test their technologies for them, thus saving time. The laboratories furnish a copy of the certified test results.

A description of technology standards and/or toolkits can be found at http://csrc.nist.gov/encryption/index.html and are summarized by the following terms.

Hashing. Cryptographic modules testing (CMT) laboratories are currently using a software-testing tool, the Digital Signature Standard Validation System (DSSVS) v2.3 to test DSA/SHA-1 and SHA-1 implementations. The various tests are described in the DSSVS user's guide.

Data encryption. Data encryption standard (DES) and Skipjack tests are described in the National Institute of Standards & Technology (NIST) Special Publication 800-17, "Modes of Operation Validation System (MOVS): Requirements and Procedures." Triple DES tests are described in NIST Special Publication 800-20, "Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures."

Cryptography modules. Cryptographic module testing is performed with the derived test requirements for Federal Information Processing Standard Publication (FIPS PUB) 140-2. It lists all the vendor and tester requirements necessary to test a cryptographic module and is the basis of testing conducted by the CMT-accredited laboratories. Testing of cryptography modules includes identifying electromagnetic interference-electromagnetic compatibility (EMI/EMC). Vendors of general encryption modules, VPN devices, Internet browsers, cryptographic tokens and modules that support PKI can use independent and accredited CMT laboratory services. Products tested as conforming to FIBS PUB 140-1 commonly are accepted by US federal agencies.

PKI. X.509 path-validation tests. These tests are described in the "Conformance Testing of Relying Party Client Certificate Path Processing Logic" document. The description of technology standards and toolkits can be found at http://csrc.nist.gov/encryption/index.html. The goal of these tests is to address the X.509 features used in the Department of Defense Class 3 PKI.

One draft regarding PKI interoperability is being evaluated by the Federal Bridge Certification Authority (FBCA) "Guide for Applying for and Interoperating with the FBCA." The description of technology standards can be found at http://csrc.nist.gov/encryption/index.html. In general, the functions to be tested include key management, PKI interface, and path-development and processing.

Key management functions include

• generating key pairs

• storing keys and related certificates

• storing trust points

• data recovery

• random-number generators

• importing and exporting keys.

PKI interface functions include

• communication protocols

• requesting and obtaining new certificates for subscribers

• retrieving certificates

• checking certificate status

• retrieving archived certificates and certificate revocation lists (CRLs).

Path development and processing functions include

• path development

• path processing

• checking certificate status extension processing.

Digital signatures. Refer to "Hashing" in this section.

Message and entity authentication. Testing is not available for message and entity implementations.

Operation-maintenance

Authentication and non-repudiation cannot be accomplished without the ongoing protection of an individual user's private key. Therefore, private keys must be protected so their secrecy is preserved. Protection of a cryptographic module within a security system is necessary to maintain the confidentiality and integrity of the information protected by the module.

In addition to protecting cryptographic modules, the set of processes and mechanisms known as key management supports the keys throughout their life cycle. This procedure includes the generation, distribution and maintenance of ongoing keying relationships between parties, including replacing old keys with new keys as necessary. The framework of key management is a company's comprehensive security policy. This company-wide policy also includes definitions of the actual operation of other PKI components.

In addition to describing the maintenance of the technical and procedural controls that keep the computer environments performing as required, the associated predicate regulation specifies that records be maintained for periods that can exceed 10 years. Because electronic records may be kept for a long time, the system containing signed records must be maintained with environments designed to support long-lived signatures of 5, 10 or more years. Furthermore, the system must provide an archive for the safe, tamper-resistant storage of signed records. The signing format of the record should be archived in an application-neutral format, which can reproduce the signed record long after the original signing event. The selected system must have a secure archive for storing signed documents, extensive search and retrieval facilities, and the utilities to reproduce evidence of the signed records, the signatures-records linkage and trustworthiness of signed records.

Periodically, power-up self-tests and conditional self-tests must be executed and the results recorded. The purpose of the tests is to ensure that the cryptographic module is functioning properly. As part of the operation of the security infrastructure, periodic audits of the PKI components, backup to the certificate server, and contingency planning and disaster recovery procedures must also be completed.

Conclusion

The combination of current security technologies, associated infrastructure and cryptographic product-services families offers promising solutions to the security issues shown in Figure 1. Today's leading Web browsers, Web servers, e-mail systems, IPSec-based VPNs and many other applications have built-in support for the use of digital certificates. These technologies are robust, cost effective, and ensure trustworthy records and satisfy Part 11 requirements by

• minimizing the risk of imposters or those who claim to have been impersonated

• minimizing the risk of undetected message tampering and forgery, and of false claims that a message was altered after it was sent

• retaining a high degree of information security, even for information sent by means of open, insecure, but inexpensive and widely used channels.

Any mention of products or references to organizations is intended only to convey information; it does not imply recommendation or endorsement by Networking and Computing Services (NCS) or Johnson & Johnson (J&J), nor does it imply that the products mentioned are necessarily the best available for the purpose.

The opinions expressed in this article are strictly those of the author. They in no way represent the views of NCS or J&J.

Reference

1. Good Automated Manufacturing Practice Forum, "Guide for Validation of Automated Systems in Pharmaceutical Manufacture, Rev. 4," December 2001.