Slashdot Mirror
Seeking a Practical Guide to Digital Signatures?
ScuzzMonkey asks: "I work for a small company trying to streamline some business processes in Washington State. As a part of this initiative, we're considering implementing a 'paperless' contracts system. In order for this to work out, on our end, we need a legally acceptable method of electronically signing the contract documents that we receive via fax from our sub-contractors (at this time, they will still be signing manually; this may eventually move to e-mail and digital signatures on their end as well as they become more capable of dealing with us on that level). On the face of it, this seems pretty straightforward. I set up some sort of certificate or some such for our employees responsible for signing these documents, and they simply review the TIFF attachment that comes in from the fax software and 'sign' it with their digital signature via a selected program. With the passage of the E-Sign Act (PDF) in 2000, it seems like this should be every bit as solid in court as a written signature. But while I've been able to find quite a lot of information on the web about the theoretical ramifications of this law, there's not much on practical implementations. What sort of software should I use? Do I need a third-party issued certificate? If so, do I just need one for the company, or one for each signer? What certificate authorities would you recommend? Do some certificates work with some software but not other software? What about this program from the state? Has anyone done this successfully yet? Any other stumbling blocks I should be aware of here, either legal or technological?"
Are your customers willing to do this? While I'm sure there's a contingent out there that is willing to dive in and get rid of all the face to face visits and FedEx packages, I'm not so sure that they number past a few. Most companies that I have the pleasure of dealing with would much rather seal decisions with a pen than email.
:-(
A Google search on this topic pops up quite a bit of broken links.
I have been pwned because my
It signs messages and files just fine. What's wrong with using it?
Paperless office is what Notes all about.
Two points tho:
It's expensive, but very secure
The FAX solution is an add on product offered by many vendors.
Your best path, especially if you have no Notes experience, is to get a consultancy (IBM could recommend you one) who have done this before to give you proposal which you can then compare to alternate non-notes solutions.
Fnord! Any sufficiently undocumented code is indistinguishable from magic.
The problem is that you can't keep those keys in a secure server watched 24/24 by armed guards --- you must hand them out (or hand a key to a key to a key) to the actual humans who will have to use them, and there you have a weak link in your security chain: how can you prove that the key can't be stolen? Or are you willing to be liable for anything signed with a stolen key?
Things can be enhanced by having some kind of physical key (a credit card or better, one of those small round things that you put in an actual keyring) attached to every person, to unlock his keys; usable only with his personal password at a secure desk within the walls of the company. Usual protection against Tempest are useful, to prevent anyone from stealing your passwords, etc.
If you find a cost effective way to manage digital signatures, you might find that you can make an awful lot of money selling the process to other companies, as part of streamlining their internal IT processes.
Just my .002 mg of gold worth.
-- Faré @ TUNES.org
Reflection & Cybernet
You obviously need to set up a PKI, which is neither cheap nor simple. Actually, it is simple to install and get running, but the administrative part of it is a pain if you want it to be legally binding. I set up the first production PKI in the federal government back in 1994, which is still up and running and providing digi-sig's for a procurement application. Today, you need two people to simultaneously badge in to enter or leave the room that hosts the CA, as well as two people to issue certificates (kinda like launching the nukes in the WarGames movie). If you want it to be totally standards-compliant, I'd suggest looking at Baltimore Technologies offering. Entrust also has a fine product suite.
The legal challenge is in the Certificate Practice Statement and the Certificate Policy Statement. But there's many templates available on the web that you can use to get something going. Your goal is total non-repudiation. If it's implemented correctly, you'll have it.
I could go on and on about the topic, but don't have the time. I hope the limited input is of some use though.
He makes some good points here: Why Digital Signatures Are Not Signatures
Since the major issue with digital signatures is proving a particular key pair belongs to a specific entity, why not merge the two signature technologies (digital and physical)? What you do is have someone print their public key in a contract, with language stating that they authorize that public key to verify digitaly signed documents (might have to also specify the specific technologies in the contract), then sign that contract with pen & ink. You keep that contract on file, so you then have physical proof of ownership of that public key, and have a better chance of it holding up in court.
With the passage of the E-Sign Act (PDF) in 2000, it seems like this should be every bit as solid in court as a written signature. But while I've been able to find quite a lot of information on the web about the theoretical ramifications of this law, there's not much on practical implementations.
I appreciate that your ask slashdot involves technical rather than legal issues. However, based on this quote is doesn't look like you've talked with a legal advisor. Consider what would happen if the means that you selected to implement your digital signature solution turns out to be invalid -- you might have problems enforcing all of your digitally signed contracts. Obviously a bad thing. Fully understanding the implications of a statute involve a lot more than reading the staute and doing a quick Google search or two.
This post is not intended to constitute legal advice. If you need such advice, see an attorney, not slashdot.
"The dinosaurs died because they didn't have a space program." - Niven
I am very worried about the fax component of this. If you sign a document and then fax it somewhere, the person recieving the fax can't validate the signature. Digital signatures gaurantee that the document is bit-perfect, and the process of encoding an image into a fax transmission is substantially less than bit-perfect. So if the recipient can't verify the signatures becasue you are transmitting them in a lossy way, it doesn't seem like there is much point in signing them in the first place.
You have the right idea, but your technology is about a decade out of date.
You can get smart cards/crypto cards or dongles that keep the keys on the card. It's *never* revealed, and all crypto is done on the card or dongle. They aren't expensive - I bought a set of 5 cards for $100, and the Linux development kit including reader was under $100.
However this system use PKIX, not OpenPGP, and the infrastructure is different.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Of course a smart card is useful only if it does some crypto (otherwise it is but junk). But that does not suffice to guarantee security, and it is utterly stupid to pretend that "all crypto could be done on the smart card".
For instance, only whole-system security can guarantee the WYSIWYS property (What You See Is What You Sign) -- something essential for any legally binding signature: the security of the workstation where the user signs stuff is thus of primary importance; don't run any unaudited or untrusted software on it. Also, you'll still want to double the card security with normal password security; they don't fight the same kind of attacks, and the combination thus raises the security considerably.
Additionally, you might require a central (but replicated) server to stamp any document before it is considered binding, so as to be able to keep track of what your company has signed. Otherwise, you might wake up with bad surprises, the day you learn you signed for millions worth of debt.
Finally, you must provide customers a trusted way to check whether a certificate is signed, and what it really means --- the fact that the other contracting party may trust you is the whole point of a digital signature; if it does not participate in creating this contractual value, your digital certificate is not worth the electromagnetic field it is encoded with. Oh, and so that your customers may give any value to the contracts you signed, they must understand it, so you'll want to include within the signed contracts a short and effective description of the contract, and not just a bookful of legalese (lawyers are more efficient than cryptographers at making a text unreadable).
Another .002 mg of gold worth.
-- Faré @ TUNES.org
Reflection & Cybernet
The basis of a valid electronic signature is a combination of policy and code. As per Schneier's article and the E-Sig Act, deniability is the key factor. If you can provide the technology necessary to keep the means of signing secure, and can put in place a set of policies for which you have agreement on record, then you have a legally binding electronic signature.
The exact means you use to implement the technology, whether it be digital certificates or simple password authentication, is nearly irrelevant. Okay, you want to make it as secure as possible, and local regulations and/or your contracting partners may dictate your means. But aside from that, all you have to do is make sure that you have taken reasonable precautions to ensure that the signature corresponds to the person, and that intent to sign is implied in the signature. The first half is done through authentication of some sort. The second half is embodied in your company's documented policy.
For the policy, make sure that your company holds training sessions for all current and new employees who will use the system. Let them know that security of their job depends on the security of their passwords. If possible, get them to sign a form that spells out the policy, the usage, the consequences of misuse, and that they acknowledge that by using the system, the employee consents to be bound by the signature. We in healthcare call this informed consent . It maintains an audit trail that disallows deniability. The interesting point, on rereading the E-Sig Act, is that the employee may signal their intention not to be bound by the electronic signature -- but this must be written. In your policy, you may specify that the employees must agree to and comply with the electronic signature as a requirement for employment. At which point, you may remind them if they wish to withdraw their consent that they may be endangering their job in so doing.
As another poster mentioned, though, get a lawyer's (or insert other domain-specific expert here) advice on the topic. And, if you expect your electronic signature to be taken as valid by other companies, you must discuss the matter with them beforehand.
If you're going digital, go all the way and use an e-forms vendor like PureEdge which can be filled out, digitally signed, verified and archived without ever having a printed copy. Plus it's XML so you can map the data directly into a database. If you're going to digitally sign something, sign the actual document rather than a snapshot of it.
Bite the hand.
Answers in no certain order...
First, you do not have to use a public Certification Authority. In this case you are issuing certificates to a user in order to conduct business with you. My guess is that you trust yourself, so you don't need the services of a public CA.
Next, ignore E-Sign. If this is repetitive business, you need to contractually negotiate what constitutes legally binding. It is much easier to live up to the standard of "legally binding" instead of the standard of "non reputable". The contractual agreement should cover the due diligence requirements for both parties (you are responsible for ensuring the identity of the person you issue a certificate to, they are responsible for protecting their private key and ensuring no one else can use it) as well as risk allocation (who pays if the system fails).
Next, contrary to what my fellow slashdotters will say, you most likely will need to use commercial software. People like having someone to blame for failures, especially where legal transactions are concerned. If the software fails, or has a security problem, you want someone behind the software license with deep pockets. Also, most accounts I see using the PGP-like solution require the end user to license their own copy of the encryption/signing software (this is very typical for banks). Using commercial software means you don't have to eat the administrative overhead of supporting the software.
Finally, I would get some budget and hire a consultant who has done this before. It is quite doable, but there are some rabbit holes you can fall into. Check with RSA or Entrust for a senior consultant with architectural experience. This is a place where I would go for a specialist, and not one of the Big 5 (or is it 4 now) or a local VAR. If you want to do "electronic" signatures instead of digital signatures, Silanis up in Canada is arguably the king of this area.
-LW
I work for a financial planning firm that was looking for a digital security policy that would involve digital signatures/encryption.
And I ran into the same problem that you did. Every article on the web seems to focus on theory of the matter, as well as some type of history on the topic, but they never talk about typical scenarios, recommended applications, etc.
Although it's only my opinion, I think I have figured out why: almost no one does this on a public level. For example, in our firm, we may decide to use some version of PGP that will attach to Microsoft Outlook so we could all have private keys and send mail inside of the firm. Another option is to use a CA server, so we can use the S/MIME capability of Outlook. And the list goes on. There are a hundred different ways of doing it, and none of them are compatible with each other. So, basically, you're forced to pick a system and stick with it, and any hopes of using your system publically will be next to impossible.
It's a very messy arena, especially when you'll be dealing with the public, your clients, or providers, because then you are taking on nasty technical support responsibilities.
In my experience, I have come to realize that a few things are (possibly intentionally) left unclarified in the signature/encryption area. First of all, if you are only doing internal signatures and encryption, you don't need to get a "certificate" from any of the public vendors. You can generate your own from your very own CA. (All a CA really is is a few scripts that generate keys). Programs that use S/MIME are almost plug-and-go for security, just install the certificate into the system (in Windows, you do this in Internet Explorer), and that's it.
If you are doing anything more complicated than that, things get very hairy. You might want to try a different way to solve your problem (possibly even non-technically), or hire a consultant who is highly experienced with digital signatures. It is a very confusing and complicated arena which I don't fully understand myself, but, it seems like if you can pull it off, you'll be WELL ahead of the curve of many other businesses.
This sig provides no comical value.
Dude, it's a legal signature to type your name in an e-mail. If you want some more intent, type "/s/" for signature.
/s/