From: Derek Wimmer [derek.wimmer@wimmersystems.com]
Sent: Friday, July 09, 2004 10:24 AM
To: fdadockets@oc.fda.gov
Subject: Docket No. 2004N-0133

These comments were scheduled to be presented at the FDA public meeting for June 11, 2004. The original presentation is available at EMC 25 under the comments for this docket, but is included again with these comments for completeness. This presentation was also given in the FDANews audioconference "Re-examining Part 11" on June 17, 2004.

I wanted to give this presentation at the FDA meeting because I feel that electronic record authenticity and integrity is a very important issue, but I haven't' seen it getting much discussion in the public forums. It seems to be getting overshadowed by what FDA doesn't plan on enforcing, or what they may be doing in the future, and this issue is something that FDA has stated that is not subject to enforcement discretion.

The presentation is entitled "Cryptography Facilitates Record Security and Integrity", and on the second slide there is some background information on me and what we do. For background information, I've worked in the pharmaceutical industry both in the lab and in QA, and I have a product that's been on the market for several years implementing the core concept of this presentation. This product has been adopted by several major pharmaceutical companies to address Part 11 compliance concerns.

Slide three states the question that FDA wanted input on for this meeting "What requirements would preserve record security and integrity and ensure that records are suitable for inspection, review, and copying by the agency?" The title of the presentation answers that: using cryptography.

Why is this issue even important? You know that with a digital file, if you change the data in the file that there is no way to tell if a change had been made. The bytes are simply overwritten. And that leads to a requirement in the software for an audit trail, to document the changes. But you are relying on the software to do that, and in the digital realm one of the ways you can have fraud is through hacking. So with hacking you are changing the file without using the software, so there isn't going to be an audit trail. How do you detect this? You need some kind of authenticity and integrity check in the software so you can see if someone has hacked the file.

Now if you say that isn't necessary and you can rely on procedural controls for this, think of this analogy. When I used to work in the lab, we had to check out our lab notebooks. The pages all had company letterhead, were bound into a numbered volume, and each page was numbered. So there wasn't an easy way to toss a page out and replace it. 

Entries were made in ink, so you had to line-through changes. Software without an authenticity/integrity check would be like having such a system, but allowing people to write with pencils. So how can you tell if an entry has changed then? Well, we train our people not to use the erasers, and our SOPs say not to use the erasers. I don't think that would get you very far in an inspection.

The next few slides go into trying to define each of the parts of the question, to highlight that there is a broad scope to this issue. 

Preservation (slide 4) ranges over a long period of time and in various systems, some of which may be outside the bounds of the software or procedural controls. The first period is when the record is used; this will be within the host electronic record system. Next will be the retention period. Typically, this is within archives and thus outside the host electronic record system. Another period is during submission; this would be when the record is submitted to outside parties, such as the FDA or a sponsor; in such a case the record is also outside the host electronic record system. Therefore, we should be concerned about preservation not only within the host electronic record system, but also how records will be preserved outside of it.


Security (slide 5) in this context addresses how a system will prevent alteration to the record. I split this into two categories, active and passive. Active controls will limit access to the records, limit ones ability to alter the records, and primarily relies on physical or computerized controls to achieve this. Examples of active controls include hardware, software, card keys, and logins: these are all active because they keep you from doing things. Passive controls don't prevent anything from being done, instead relying more on deterrence. Examples of passive controls include the text (and interpretation) of 21 CFR 11, laws, ethics, and a company's SOPs. Of themselves, these things don't physically prevent anything from happening to records, but they can act as a deterrent to an individual that is aware of them and understands the implications of violating them. The application of cryptography in the context described here would be considered a passive control. It does not prevent alteration of the record, but does act as a deterrent if its use is known, because the individual would know that any alteration would be detected. (Note that cryptography currently plays a major role in active controls in uses such as password storage, key cards, token systems, and the like.)

Integrity (slide 6) for an electronic record in this context basically means that the entirety of the record is there just as it was when it was last used. Corollary to this is that you can detect alteration to the record. There are two ways to detect alteration: (1) Using a "reference" copy where you compare byte-for-byte such as a copy on CD. (2) Using a "fingerprinting" method, where you compare a checksum of the record at the time of viewing and compare it to a stored, trusted checksum. This is what cryptography lets you do on electronic records: very efficiently and securely compare things to see if there are changes.

Slide 7 shows how Wimmer Systems implemented this in a part 11 system for spreadsheets in four steps. It uses a digital signature system, which is basically as secure means of generating checksums on data. The process is: (1) When the spreadsheet is saved, the program generates a secure digital signature of the file data. (2) The digital signature is embedded in the spreadsheet file. (3) At the next usage (which may be on another system), the program excises the original digital signature and generates a new signature of the file data. (4) The new and old signature are compared to verify the security and integrity of the spreadsheet. If the two match, we are certain that the file has not been tampered with.

This demonstrates a real-world application of how you can have an integrity check on a file, where it only requires the file and the small fingerprint, and it can be carried along with the file throughout its lifetime.

This type of system meets the requirement presented on slide 8; that of the record being "suitable for inspection, review, and copying by the Agency". Since the FDA wants the records to be suitable for inspection, review, and copying, it follows that the security/authenticity controls should be maintained for the records. Carrying the fingerprints for the records allows you to do these things, as long as each new system it hits is able to process that fingerprint. That is how our system works: if the FDA has our product installed, or a verification tool, the FDA will be able to verify the authenticity of the records submitted.

Slide 9, why does a cryptographic fingerprint method meet these requirements? For preservation, the fingerprint can be archived or transmitted with the record, and it does not require the host electronic record system to maintain preservation. For security, fingerprinting deters record alteration by virtue of being able to detect the alteration. 

Also, secure cryptographic methods are available for fingerprinting. For integrity, fingerprinting allows a high degree of verification of record fidelity. And for suitability for inspection activities, fingerprinting methods are independent of the host electronic record system and allows for the portability of electronic records.

Slide 10, what is the burden of requiring something like this? Technologically, all of this is available already. Cryptographic methods are built into commercial operating systems, are commonly used in multiple applications (such as Internet browsers), and there is a wealth of knowledge and tools out there to use them. There is not a high cost for implementation, you just have to code it in. Many are free to use and the infrastructure for some has already been built. But the burden of doing so is less than having no requirement at all, because you specify a path to take rather than have people burn a lot of energy trying to figure out other ways to do it because they think that a cryptographic method won't be accepted, is too hard to do, costs too much, etc. And the burden can be reduced further by use of standards (such as XML digital signatures), and commercial systems. Such as with our product, Adobe digital signatures, and so on, if each person individually were to create something similar, overall it would cost a lot. But we're able to spread that cost out over a large number of systems, so the burden is considerably less.

In conclusion, I believe that requiring appropriate cryptographic methods will help preserve record security and integrity and facilitate ensuring that records are suitable for inspection, review, and copying by the agency. The requirement would be technology-neutral, as the term "cryptographic methods" does not mandate the use of a specific technology. The burden of this requirement is not great, as the tools to implement them are readily available at a low cost and are commonplace.

Best regards,

Derek Wimmer
President
Wimmer Systems, Inc.
P.O. Box 739
Liberty, Missouri 64069
Tel/Fax 1-800-795-3227
Mobile 816-728-2387
http://www.wimmersystems.com