Seeking a Practical Guide to Digital Signatures? 65
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?"
First question: (Score:2, Interesting)
A Google search on this topic pops up quite a bit of broken links.
Re:First question: (Score:2)
I'm actually more worried about the larger companies we deal with (GE and the like). They are the most technologically advanced, but also the most entrenched and the least likely to bargain with us.
Use GnuPG (Score:2, Insightful)
Re:Use GnuPG (Score:1)
Re:Use GnuPG (Score:2)
Re:Use GnuPG (Score:2, Insightful)
The problem you have with this is not the signing itself, but with key trust relationships. Basically I can create a key with any name & email address - how do you know that it is actually me? There are several methods to solve this. Either you have to meet in person and give them the key there, or it has to be signed by a mutually trusted 3rd party. Meeting in person usually defies the point of public key encryption - you might as well just use symmetric if you can give them the key. The second option is a trusted 3rd party - but who do you trust that much, if you recall there was a slashdot story a while back (can't find the link) about Verisign signing dodgy Microsoft certificates.
Gnupg actually uses a web of trust system - if you have verified someone's key in person, and you have signed it to say you trust it, then it assumes you trust any key they sign. This introduces another weak point though. Even if you only sign keys after personally verifying fingerprints, do all the people who you've signed?
There are several program out there you can use, but if you are interfacing with customers using this, either you verifying their signatures, or they checking yours - there are going to be 2 problems. Do they trust the tech in general, and are they prepared to trust it, and how do you trust each other's keys. There probably needs to be a high profile 3rd party that you can both trust to authenticate against - but are there any at the moment for use with general signing tools? (Something like the certificates used in https/SSL, probably)
Re:Use GnuPG (Score:1)
David
Re:Use GnuPG (Score:1)
Re:Use GnuPG (Score:2)
I tried the only one I could find, WinPT, and it just flat out doesn't work on my set up. I might be able to fiddle with it, but frankly, if it doesn't work out of the box, it's no use--I need something fool proof enough that both employees and contractors can double-click 'Setup' and start using. Don't even talk to me about teaching them the command line. Unless you've got alternative front-end recommendations, this is a dead-end for commercial use.
Re:Use GnuPG (Score:2)
David
Re:Use GnuPG (Score:2)
At any rate, as comprehensive as pgpi.org is, they do not show any Windows compatible front-ends for GnuPG, so as attractive as it is from a licensing perspective, it's probably not an option. I appreciate your taking the time to follow up on the conversation, though.
Re:Use GnuPG (Score:2)
David
Look at IBM Lotus Notes (Score:3, Informative)
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.
Re:Look at IBM Lotus Notes (Score:2)
If this were from scratch, in a completely non-wired company with no existing infrastructure, that may well be an excellent option. But I want to leverage what I have already, or it starts to not really be worth it.
Thanks!
Re:Look at IBM Lotus Notes (Score:2)
_If_ you trust Lotus/IBM, who have been known to put backdoors into their export versions to give the NSA substantial portions of the encryption keys. And their code hasn't been vetted by the security community. And your actual level of security is highly dependent on your key management scheme.
Not to say it's a bad idea, but "Notes is very secure" is a pretty glib answer.
Sumner
Re:Look at IBM Lotus Notes (Score:1)
Really what I was saying is it's a mature system that is secure and used by many military organisations because of that security, complete with digital signing. However using open source does mean you can be sure it really is well written, unless someone throws a grid computer at it...
Re:Look at IBM Lotus Notes (Score:2)
Good points but I guess it all depends on whether the stuff you're doing makes you a criminal in the eyes of the gov., whether you think a competitor has some control over a portion of the gov., whether IBM wants to buy you
It's not even a question of doing something illegal or fearing some nutcase government conspiracy--individuals within the government can use their priviledged access against you. Witness yesterday's revelation [cnn.com] that a pair of FBI agents may have been (they haven't stood trial yet) using FBI data to manipulate the stock markets. Or the current case [cnn.com] involving an agent accused of feeding information to the mob.
As soon as individuals have the information, it's only as secure as they're willing to make it. And that was my point. As I said, if you're protecting $100 secrets and you think it costs $10,000 to corrupt the agents who could get at your data, that's probably fine (unless, of course, your secretary also has a copy of the key and can be bribed for $20....) But you need to understand those tradeoffs.
However using open source does mean you can be sure it really is well written, unless someone throws a grid computer at it...
_if_ it's widespread enough and mature enough that the community has had time and inclination to thoroughly examine it. I don't think you want to trust an algorithm or a complex system just because you've examined it yourself and think it's secure, even if you're Ron Rivest or Bruce Schneier. But components like PGP, ssh, and SSL have been examined pretty well and you can expect to have a good idea of how secure they're considered by the security community; the most popular open-source implementations have been examined closely as well, (even they still turn up minor problems from time to time).
Of course, whatever you choose you have to implement it correctly.
Sumner
The weak link is the human (Score:3, Informative)
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.
Re:The weak link is the human (Score:2)
smart cards (Score:2)
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.
smart cards are no remedy to dumb humans (Score:1)
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.
Re:smart cards (Score:2)
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.
Until someone reads the key back off the card, which has been done with cheap ($50) hardware for "tamper-proof, unreadable" smart cards.
The real key is the human factors: don't let anyone get their hands on the key who you don't trust to keep it reasonably secure, and make sure that people understand how important it is.
Also, remember that the current setup is only of marginal security; don't spend millions of dollars to make the digital signatures bulletproof when someone can either forge a paper signature, fast-talk the employees into authorizing a purchase/signature/whatever, or otherwise circumvent the crypto. The free tools (gpg/OpenPGP or openssl based S/MIME solutions), if properly implemented, are more than sufficient to force would-be imposters back to their old tried and true ways.
In other words, worry more about how you implement the system (eg: key management) and how you train the users than about the particular cryptosystems and techie gadgets you choose.
Sumner
Re:smart cards (Score:2)
That having been said, the human factor is almost always the weakest link in any well-designed security system. Train, train, train --- and then have an occasional check to make sure that people don't still do silly stuff in spite of their training. (like giving their password to 'Mike from the security team', or writing it on their card).
Digital Signatures (Score:1, Informative)
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.
Re:Digital Signatures (Score:1)
Bruce Schneier on digital signatures (Score:3, Informative)
Re:Bruce Schneier on digital signatures (Score:2)
Just a thought... (Score:1)
Talk to a lawyer (Score:1)
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.
Re:Talk to a lawyer (Score:2)
Faxes and Signatures Don't Mix (Score:1)
Re:Faxes and Signatures Don't Mix (Score:2)
Policy, not just code (Score:2)
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.
Why go half-way? (Score:2)
If you're going digital, go all the way and use an e-forms vendor like PureEdge [pureedge.com] 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.
Re:Why go half-way? (Score:2)
We still get significant savings from this, though. It reduces a TON of costs in storage, paper, forms management, and physical transportation (previously, signers would have to come back to the main office to sign contracts--now, we can e-mail it out and get it back same day when they are in the field). There's almost no reason that we would ever deal with hardcopy on our end--it's just as easy to review the documents on screen. Everyone and their dog has a TIFF reader.
The basic run down on signatures (Score:1)
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
A reason, and my experience (Score:1)
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.