Technologies Supporting Electronic Records Integrity, Part 2

Part II of this series depicts the combination of the tools described in Part I. The focus is on mitigating threats and vulnerabilities related to e-records integrity.

Cryptographic Technologies Applicable to E-Records Integrity

The electronic environments, such as computer systems, pose particular challenges establishing the integrity to the e-records. This is due to the ease technique with which e-records may be altered and copied, which can result in the possibility of a multiplicity of versions of a particular e-records and the associated document. 

Trustworthy computer systems provide the confidence to the regulated users that the e-records are the same as those expected, based on a prior reference or understanding of what they purport to be. This expectation includes that the e-records have not been altered in an unauthorized manner (NIST SP 800-33 and IEEE Glossary).

Methods used in storing, transmitting or representing e-records may result in misrepresentations, must be investigated and the investigation results documented. 

A range of strategies for affirming the reliability and integrity of e-records have been developed, and the choice of a particular method will depend upon the criticality for which e-record integrity verification is required through a risk analysis process. Hashing and digital time stamping are 'public' methods, which confirm the integrity of an e-record which in the case of the latter method, involve a specific time. 

Another class of methods for establishing authenticity of an e-record includes encapsulation techniques and encryption strategies. A digital watermark can only be detected by appropriate software, and is primarily used for protection against unauthorized copying. Digital signatures are used to e-record authorship and to identify the people who have played a role in a document. 

The types of security services that are needed in support to e-records integrity vary depending upon the requirements of the application managing the e-records and the e-records by itself.  As a rule of thumb, it is needed to deal with identity and access management, encryption of e-records retained at rest, and encryption of the e-records in transit (e-records moving from storage to storage). 

The required security services must be designed in a way to encourage compliance with the principles of e-records integrity .

Every so often ignored are the links of the e-records security solution at the e-records level, and the security solution for the entire enterprise.  These have to be integrated.  If they don’t, they are really working against each other. 

E-records integrity is an essential element of any successful enterprise information technology (IT) program.  It is required to have a strong plan behind it, and a strategy embracing all of the major issues.

E-Records at Rest

E-records at rest are retained by computer storage. Computer storage is a device that records (stores) or retrieves (reads) e-records from any medium, including the medium itself.   

E-records should be secured by both physical and electronic means against damage .  This guideline is found in several worldwide regulatory and guidance documents and it is applicable to short and long term storage of e-records. 

Critical e-records retained by computer storage can be protected via encryption or a comprehensive service such as PKI.

Access Controls and Authority Checks to Computer Resources

User access controls to computer resources are the basic security function for the reason that trustworthy of the computer system may be compromised even if the e-records themselves are not directly accessed. 

User access controls shall be configured and enforced to prohibit unauthorized access to, changes to and deletion of e-records (EMA Annex 11-12.1 and US FDA 21 CFR 211.68(b)).

Access controls and authority checks “ensure that people have access only to functionality that is appropriate for their job role, and that actions are attributable to a specific individual.” 

Access controls are applicable to the system administration functions as well.  These functions can be in the applications or infrastructure levels. “System administrator rights (permitting activities such as e-records deletion, database amendment or system configuration changes) should not be assigned to individuals with a direct interest in the e-record (generation, review or approval).”20  

Public-key certificates can be used to authen¬ticate the identity of a user, and this can be used as an input to access-control decision functions. Access-control deci¬sion functions are defined through access rights lists - for ex¬ample, access control lists (ACLs) with functions such as use, read, write, execute, delete, or create privileges. 

In Windows, as an example, 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 sys¬tem access control list (SACL). 

A DACL is a list of user accounts, groups, and computers that are allowed (or denied) access to the object. DACL’s also have a list of access-control entries (ACEs) in which each ACE lists the permissions granted or denied to the authentication (EMA Annex 11-12.3). This feature is a challenge - response exchange with a new key that is used at each log-in.

A SACL enables administrators to log attempts to access a secured object. Each ACE specifies the types of access attempts by a specified trustee  that cause the system to generate a record in the security event log. An ACE in a SACL can generate audit records when an access attempt fails, when it succeeds, or both. 

As an example of access controls in a typical manufacturing room, an operator logs into the system to per¬form 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 con¬firm whether the area and equipment were cleaned and released for production. The system returns the appropriate authoriza¬tion to perform the operation. In this example, authentication, public-key certificate certificates, and ACL are combined to pro¬vide the necessary control to operations.

ACLs must be current and reviewed on a regular basis.

Audit Trails Controls

As part of the integrity of e-records, audit trails refer to a journal that records modifications to the e-records. The person or automated processes operating on the user's be¬half may perform these modifications. An audit-trail mecha¬nism provides the capability to reconstruct the modified e-records and therefore does not obscure a previously recorded e-record. 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 the e-record or an e-record by itself. The controls associated with e-records are applicable to electronic audit trails.

Controls to the audit trails include: restrict user access rights to audit trial file to prevent e-record amendments; switch off the audit trails; time stamp must be reliable (refer to Time Controls); the system administrator rights should not be assigned to audit trails review or approval; record-audit linkage; audit trails cannot be modified; access to the audit trials is limited to print-read only. 

The combination of authentica¬tion, public-key certificates, encryption, and ACLs provides the mechanisms to control the access to audit trail related files.


Authentication is a process in which the credentials provided are compared to those on file in a database of authorized users' information on a local operating system or within an authentication server. If the credentials match, the process is completed and the user is granted authorization for access to the applicable computer resources. 

There are various ways to authenticate a person: user IDs and static passwords; user IDs and dynamic passwords; biometric devices.  Certificate-based authentication is a user IDs and dynamic passwords that utilize public-key certificates. 

The image below refers to the typical authentication via user id and static/dynamic password.

The gathering of the identification documentation (EMA Annex 11-2) of a regulated user is typically performed by the regulated entity Human Resources.  Similar regulatory requirement is summarized in US FDA 21 CFR Part 11.100(b). 

The authentication of an entity in a PKI-enabled environment is performed by using a CA. The CA issues and manages security credentials and public-keys for message encryption and de-cryption.  The objective of a security credential is to associate an identity with a public-key value.

The identity is not of the user, but of the cryptographic key of the user placed on file in a database of authorized users' information on a local operating system or within a certificate server. Having a less secure key lowers the trust we can place on the identity.

The certificate-based authentication is a technique for strong authentication. A party wishing to be authenticated presents a public-key certifi¬cate. If the certified party is still trusted in the organization, then the certificate server trusts that the party is who it claims to be. One benefit of certificate-based authentication is that the entity does not have to have an established relationship with, for ex¬ample, a server before being authenticated.

The digital signature is another method to authenticate a person.  This method prevents denying by the sender have sent the message. When the verifier validates the digital signature using public-key of a sender, the verifier is assured that the signature has been created only by the sender who possess the corresponding secret private key and no one else.

The authentication of a server, as an example, can be performed using a computer networking protocol. Such protocols include mechanisms for servers to identify and make connections with each other. 

Secure Sockets Layer (SSL) is an example of a computer networking protocol using cryptographic technologies that authenticates regulated users and performs encrypted communication between servers and regulated users. Using a cryptographic system, the identity of a remote user (or system) can be established. A typical example is the SSL certificate of a web server providing proof to the user that he/she is connected to the correct server.

The SSL protocol establishes an encrypted link between a server and a regulated user, typically a web server (website) and a browser; or a mail server and a mail client (e.g., Outlook). By authenticat¬ing a server, the person is assured communication with the correct site. SSL also signs the transmitted e-records so the person is assured that the e-records has not been changed in transit. Server certificates follow the X.509 certificate format.

Security of Electronic Signatures

The output of a digital signature, hashed data, is considered an e-record.  All applicable technical controls applicable to e-records are applicable as well to the hashed data. 

In digital signa¬ture implementations, it must be considered the integrity and security of the signatures private key. The degree of confidence having in the linkage between a public-key and its owner depends on the confidence having in the CA that issues the public-key certificate. 

Within the cryptographic module, the part of a sys¬tem or application providing cryptographic services such as encryption, authentication, or digital signature generation and verification, public-keys shall be protected against unau¬thorized modification and substitution. Private keys must be securely managed.  These are implemented in various other services, including unauthorized disclosure, modification, and substitution.

Provisions in X.509 compliant public-key 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 security policies that detail the operational rules and system features of CAs and other PKI components. Logical security and proper configura¬tion to the CA, certificate server, and security server help en¬sure security during the creation and management of public-key certificates.

The private key may be stored in a user's local disk in an en¬crypted format or as part of a token that interfaces with the computer. Personal cryptographic tokens have been con¬sidered 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. 

Signature E-records Linkage

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 e-record. This requirement is consistent with 21 CFR Part 11.70 and EMA Annex 11.14(b).

In addition, any changes to the e-record after an electronic signature has been assigned should invalidate the signature until the e-record has been reviewed again and re-signed .

The above requirements support the integrity of digitally signed e-records. It is vital to consider the integrity and security of the main components of the digital signatures: the PKI components. The level the user is confident about the linkage between a public-key and its owner depends significantly on how confident the user is about the system that issued the certificate that links them.

In addition to the system issuing public-key certificates, access-control technologies, and procedures, the signature and e-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 e-records. A digital signature is linked to an e-record by incorporating an encrypted message digest of the e-record into the signature itself. This link is retained for as long as the e-record is kept and provides the trustworthiness of elec¬tronically signed e-records for that period of time.

Time Controls

The digital time-stamping service (DTS) issues a secure time stamp that can be used for digital signatures and audit trails. The DTS includes the time, a hash of the e-record being time stamped, and a time certification.

The DTS gives strong legal evidence that the contents of the time stamped work existed at a point-in-time and have not changed since that time. The hashing as part of the DTS maintains complete privacy of the e-records themselves.

The workflow of the digital time stamping practice consists of a message digest created from the e-record and sent to the DTS. The DTS sends back the time stamp, as well as the date and time the time stamp was received, with a secure signature. The signature proves that the e-record existed on the stated date. The e-record contents remain un¬known 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 public-key certificates provide the mechanism to au¬thenticate the source (device checks) of the time stamp in the audit trails and electronic signatures. Access-right lists and public-key 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 coordinated universal time. This technology, which in some cases is com¬pliant with X.509 is tied into a time-calibration service. Applications or computer logs may require time-stamping services on the server.

The access controls to the time server and all associated infrastructure must ensure proper security restrictions to protect the time/date settings.  

The time controls using cryptographic technologies provide a secure time/date mechanism that cannot be altered by personnel.  A minor change in the e-record will result in a change to the message digest.

Uniqueness of the Electronic Signatures

Electronic signatures replacing handwritten signatures must have appropriate controls to ensure their authenticity and traceability to the specific person who electronically signed the record(s) 22.

The main element for sign¬ing e-records and messages in the digital signature is the private key . Users of PKI may generate key pairs (private and public). When generated by PKI, key pair is produced by prime numbers, which are cre¬ated from large, random numbers (e.g., candidate prime num¬bers). ANSI X9.17 specifies a key generation technique. A pri¬vate 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 gen¬erates a session key that is encrypted with a server's public-key.

The uniqueness of the electronic signatures is one element of attributable e-records.

E-Records in Transit

Records must remain unaltered while in transit. The unauthorized manipulation of records, audit trail records, and replay of transmissions will be reliably identified as errors. Below explaineds the typical cryptographic controls associated with e-records in transit. 

Integrity of E-records in Transit

The integrity of e-records in transit is required by the US FDA 21 CFR 211.68. Similar requirements can be found as guidelines in EMA Annex 11-4.8 and 5.

Hash and encryption functions can be used for assuring integrity of transmitted e-records and message verification. 

Hash protects the integrity and privacy of e-records, and prevent their loss. For example, e-records must be protected when confidential patient e-records are sent to other locations. 

Records and message authentication provides the means to evaluate the integrity of the e-records and messages in transit. It involves tech¬nical controls to detect unauthorized modifications to e-records and messages. A recipient can use two (2) approaches to authenticate e-records in transit and messages:

1) Encrypt records or messages using the recipient's public-key.

A cryptographic hash function allows one to easily verify that some input e-records maps to a given hash value, but if the input e-records is unknown; it is deliberately difficult to reconstruct it (or equivalent alternatives) by knowing the stored hash value. This is used for assuring integrity of transmitted e-records, and is the building block for the Hash Message Authentication Code (HMACs ), which provide message authentication. Consequently, a way that the recipient can make sure that it is the right file is if by the sender posting the hash value publicly. The recipient can then compute the hash value of the file received and check of it matches the hash value.

Encryption protects the privacy of messages and e-records in transit between networks, including the Internet. Tools such as network diag¬nostics or protocol analyzers can read information easily as it is transmitted. To mitigate this difficult, systems such as SSL transport layer security, or virtual private networks (VPNs) can provide the necessary protection of critical e-records across networks. These solutions use encryption, digital signatures, or public-key certificate to ensure data privacy, identification of the originator of messages, and verification of message integrity.

2) Sign the records or message

A digital signature can also confirm the integrity of a message. In case an attacker has access to the digitally signed records and modifies the e-records, the digital signature verification at receiver end fails. The hash of modified data and the output provided by the verification algorithm will not match. Hence, receiver can safely deny the message assuming that data integrity has been broken.

Device Checks

The device checks are justified where only certain devices have been selected as legitimate sources of e-records input or commands.  As an example, in a network environment it may be necessary for security reasons to limit the issuance of critical commands to a particular authorized workstation.  US FDA 21 CFR 11.10(h) is a regulatory requirement related with device checks.

Public-key certificate can be used to implement any of these verifications. In the above example it can be determined the identity of the file server extracting e-records. 


The cryptographic technologies support e-records integrity in the Worldwide Health Agency GMP. Hashing, e-records encryption, digital signatures and/or services family (e.g., Virtual Private Network) are a set of tools and techniques that can be implemented to properly control the integrity of e-records.

These technical controls have an important advantage over other controls.  These cryptographic set of tools and techniques mitigate threats to and vulnerabilities connected with e-records integrity.

The following table recaps the cryptographic tools supporting e-records integrity.


The implementation of these technologies should be following a security-by-design approach. That is, design the security into devices and applications from the beginning, including the cost of doing so.


Any mention of products or references to organizations intended only to convey information; it does not imply recommendation or endorsement, 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. 

Additional Readings

1. American Bar Association, "Digital Signature Guidelines," August 1996,  http://www.americanbar.org/content/dam/aba/events/science_technology/201...

2. American Bar Association, "PKI Assessment Guidelines," May 2003, http://www.americanbar.org/content/dam/aba/events/science_technology/201...

3. Institute of Electrical and Electronics Engineers Working Groups, " IEEE Standard Specification for PKI,' http://grouper.ieee.org/groups/1363/

4. NIST Computer Security Resource Center, http://csrc.nist.gov/

5. Lόpez, O., “Data Integrity in Pharmaceutical and Medical Devices Regulation Operations: Best Practices Guide to Electronic Records Compliance,” CRC Press, Boca Ratόn, Fl., 2016.

6. PI 041-1, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments,” Pharmaceutical Inspection Co operation Scheme (PIC/S), August 2016, (Draft 2).

7. Public-Key Cryptography Standards Web site. http://www.rsasec.urity. com/rsalabs/pkcs/.

8. RFC 2527, "Internet X.509 Public-Key Infrastructure, Certificate Pol¬icy, and Certification Practices Framework," https://www.ietf.org/rfc/rfc3647.txt.

9. RSA, "Understanding Public-Key Infrastructure (PKI) Technology," ftp://ftp.rsa.com/pub/pdfs/understanding_pki.pdf.

10. Vibbert, J.M., “The Internet of Things: Data Protection and Data Security,” Global Environment Information Law Journal, Volume 7 Issue 3, Spring 2016. 

11. WHO, Technical Report Series; No 996 “Guidance on Good Data and Record Management Practices,” May 2016.

Product Added Successfully

This product has been added to your account and you can access it from your dashboard. As a member, you are entitled to a total of 0 products.

Do you want access to more of our products? Upgrade your membership now!

Your Product count is over the limit

Do you want access to more of our products? Upgrade your membership now!

Product added to cart successfully.

You can continue shopping or proceed to checkout.

Comments (0)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Use to create page breaks.
Enter the characters shown in the image.
Validated Cloud logo