Leonardo
Leonardo

Reputation: 11387

Concept of Digital Signatures for a specific scenario

My company develops an ERP for hospitals and because of some legislation changes throughout this weekend I've been reading a lot on digital signature because I need to solve the following scenario:

Each doctor will receive from the ministry of health a certificate (so there's no escape from it... government said so...) and all of his reports sent/stored in digital format must be signed with this certificate.
The certificates will be valid for one year. Each year upon renewing of the medical license, the certificate will be renewed.

Our main concern here is guaranteeing the source of the document (the sender is who he claims to be) but we must also make "impossible" (or at least infeasible) to change the content of the document (or at least that if it changes, we have to be able to tell that a modification occurred) and to "extracted and replicated" the signature...

My question is: how do I deal with this whole thing? What should I do?

PS: In your answer pls consider that:

  1. The documents will persist far beyond the certificate lifetime.
  2. The certificate might have been revoked. Documents signed before the revoke must still be valid
  3. How a 3rd party would verify the integrity of the information (document + certification)
  4. Is there not a security principle which states that information signed with a expired certificate is invalid or something?
  5. I'm really new to this area and I might be asking the wrong question...

Upvotes: 0

Views: 729

Answers (3)

Larry K
Larry K

Reputation: 49094

[Disclosure: I work for CoSign by ARX.]

Your situation is common. You're raising a number of questions. My answers:

all of his reports sent/stored in digital format must be signed with this certificate.

You can digitally sign anything (any bundle of bits). The real issue is how can the recipient or auditor easily verify that the document:

  • was not modified since it was signed (integrity)
  • was signed by the right person (identity)
  • was signed with the right intent (signer's statement)

Machine readable data, eg form data, intermediate data, etc.

Signing: For info that is designed to be later machine-read (eg a form submission), store the info in XML and sign it using the XML Signing Standard: XAdES The CoSign Signature API (SAPI) directly supports signing XML docs.

Verifying There are many on-line XML digital signature verification services, Google for them. The SAPI api also supports verifying XML docs.

Human readable documents

Signing: For a "final" document that will be read by humans (but is stored digitally, can be included in searches, etc), PDF documents are the way to go. The PDF format supports digital signatures very well. There are many ways to add digital signatures to PDF documents. For developers, the CoSign Signature Web Agent is a web service (HTTPS + XML parameter document) that handles all the UI issues of signing.

Verifying: The most common way to verify the digital signatures of a pdf is to use the free Adobe Reader. (Not the expensive Adobe Acrobat.) Adobe Reader knows how to check the validity of the digital signatures and then tells the reader/signer/auditor that the signature is valid, the document was not changed since signed, etc.

Your other questions:

The documents will persist far beyond the certificate lifetime.

Yes, that is fine. Just like a "wet signature," once you've validly digitally signed a document, that document remains signed by you. -- Even if your signing certificate later expires. As part of the verification process, the date of signing is compared with the valid dates on the certificate.

The certificate might have been revoked. Documents signed before the revoke must still be valid

Yes, that is how standard digital signatures work. Even if a certificate is revoked, documents signed while the certificate was valid will remain signed. Because date/timestamps play such an important part of the validation process, there are 3rd party timestamping services available. But they are not used for most digital signatures. Instead, create explicit management procedures to make sure that the time server is properly setup with NTP to a good source and that the system is regularly checked and verified.

CoSign signs using a tamper-proof hw device. Its clock is synched using NTP.

How a 3rd party would verify the integrity of the information (document + certification)

As I discuss above, the whole verification question is important. That's why I recommend using XML or PDF as your document types. You could, for example, digitally sign your own system's internal data structure used to represent information. In this case the digital signature would be carried in a separate data structure. This is the "external signature" scenario. It all works fine, except that an auditor would need to either build his own sw to validate or trust that your sw is doing the validation properly. A better choice is to use a format that directly supports digital signatures and which can be easily verified.

Is there not a security principle which states that information signed with a expired certificate is invalid or something?

A proper digital signature system won't allow an expired certificate to be used to sign anything. Once something is signed, using a certificate that was valid at time of signing, it stays signed unless the document is subsequently changed.

I'm really new to this area and I might be asking the wrong question...

Other questions to ask: how do you add the signer's graphical signature to the document (XML or PDF)--people expect to see it. And how do you manage/administer the certificates? Server based signing is a good solution for this. Remember that certificates should not be stored in sw for any production systems. Instead, a Secure Signature Creation Device (something hw based) must be used.

Upvotes: 1

Moez
Moez

Reputation: 134

You will also need to read the Baseline Profiles where there is a profile for long-term signatures. There is a profile for each of the formats already mentioned by Eugene. For example, if your document is PDF, you may use PAdES signatures and the LTA-Level specified in "PAdES Baseline Profile" document.

All of these documents are ETSI standards you can search for at: http://pda.etsi.org/pda/queryform.asp

Upvotes: 0

In brief, the document must be signed using CAdES, PAdES or XAdES (depending on data format) standard, where timestamping is applied and other measures are taken. These standards were designed specifically for tasks similar to yours so they address your concerns. I recommend that you read some articles about those formats. Unfortunately I don't have a link to share with you right now, but you can find a lot based on those abbreviations.

CAdES is based on PKCS#7/CMS (certificate-based signing of generic data with wrapping signatures) .

PAdES is an extension of PDF signing and is used specifically for PDF documents.

XAdES is similar to CAdES and can be used to sign XML documents and (more rarely) binary data.

Upvotes: 2

Related Questions