Yes, what you describe is a significant risk when using digital signatures. The challenge is to protect your private key.
Some alternatives:
1. The Java environment includes the tools to keep the private key in a PKCS12 (encrypted) file that is protected by a password. Choose a strong password for this file's protection. I don't know if the USPS EPM uses this Java feature. DigiStamp does.
2. Keep that password protected file on a removeable medium (floppy, CD) and then securely store. Only use floppy disk only when signing. This approach does make signing a little more difficult task. But, signing as deliberate act that requires you to retrieve and unlock the key is not bad, my opinion.
3. The most secure solution with current technology is a smartcard. This solution could include the smartcard creating the actual signature within the card after you supply a PIN directly on the cards embedded key pad. At DigiStamp, we have not yet found a smartcard with all of these qualities.
Our signing and timestamping desktop software has some information about smartcard integration here:
http://www.digistamp.com/FAQsig.htm#smart
I think any Java toolkit 'should' work on Linux. We have tested our desktop signing and timestamp software on Linux. There were some GUI display issues, but that was mostly due to coding style problems that were our fault. Interesting that porting platforms in Java does help the developer improve their code. Feel free to give our Linux desktop app a try, appreciate any feedback.
I have always been curious how to work with the OpenOffice.org
I am not sure how best to integrate with word processing software. I think of signing and timestamping as being external tasks? Maybe the integration is to help the work flow - finish writing the document and 'click' to copy the current state and sign? I like that timestamps can be applied to any type of file (graphics, audio, etc); therefore, creating the TS would be external to the software that creates the file.
In the Java environment, the code to create the actual signature is in your Java run-time. This includes access and using your private key. At www.digistamp.com we have taken the approach of seperating the protocol encoding from the actual signing step. So, we supply the source code that deals with the private key and signature creation. It is here: http://www.digistamp.com/t3override.htm
The idea is that this would be the integration point for using smartcards. Or, the user can substitute their own code that has the opportunitiy to "see" the private key. The code is pretty straight forward to create a signature using Java.
The actual encoding of the RFC 3126 message is not so critical privacy. This encoding is important to interoperability and it is important that it be done to support the various vendor libraries (e.g. MS Cryptoapi, bouncycastle, etc.)
In the Microsoft world the signature creation is using their CryptoAPI. A little more difficult and is in C, but there are some good examples available. Our C toolkit has examples if you would like.
Company I work for charges 50 cents for the first timestamp. Pricing is here: www.digistamp.com/FAQts.htm#cost We don't have a concept of expring after a year.
We have been able to reduce the prices every year for the past 4 years as customer base grows. I agree, the price needs to be less. But, the operations, development and NIST certified hardware, etc. has some cost. Our hope is that as more users convert from paper based processes they will use digital time stamps. With volume our prices will be less - pennies. I expect this price in 2 years.
Sorry if this sounds like a company sales attempt.
The Java, C,.NET toolkits are no charge.
Can you tell me where you read that the USPS is trying to patent this process?
As background, the time stamp protocol is in IETF RFC 3161. The combination of time stamp with signatures is in RFC 3126 "Long term electronic signaures" (includes multple signature, commitment qualifiers, signing comments, etc). The company I work with has made the assumption that these standards would be the basis for the presentation of binding signatures. (www.digistamp.com)
There is ongoing work at OASIS as they work on the XML versions of these protocols. The standards involve both protocol and process.
There is still the process of CA related to associated an individual to a public key. There are several of these in practice and often involve a step of using a notary. It has been interesting of the past few years in the timestamp business to see how the concept of a notary varies from country to country.
Anyway, can you tell me where you read that the USPS is trying to patent this process?
Thanks
Slashdot Mirror
Some alternatives:
1. The Java environment includes the tools to keep the private key in a PKCS12 (encrypted) file that is protected by a password. Choose a strong password for this file's protection. I don't know if the USPS EPM uses this Java feature. DigiStamp does.
2. Keep that password protected file on a removeable medium (floppy, CD) and then securely store. Only use floppy disk only when signing. This approach does make signing a little more difficult task. But, signing as deliberate act that requires you to retrieve and unlock the key is not bad, my opinion.
3. The most secure solution with current technology is a smartcard. This solution could include the smartcard creating the actual signature within the card after you supply a PIN directly on the cards embedded key pad. At DigiStamp, we have not yet found a smartcard with all of these qualities.
Our signing and timestamping desktop software has some information about smartcard integration here: http://www.digistamp.com/FAQsig.htm#smart
rick at digistamp.com
I have always been curious how to work with the OpenOffice.org
I am not sure how best to integrate with word processing software. I think of signing and timestamping as being external tasks? Maybe the integration is to help the work flow - finish writing the document and 'click' to copy the current state and sign? I like that timestamps can be applied to any type of file (graphics, audio, etc); therefore, creating the TS would be external to the software that creates the file.
Regards, Rick
The idea is that this would be the integration point for using smartcards. Or, the user can substitute their own code that has the opportunitiy to "see" the private key. The code is pretty straight forward to create a signature using Java.
The actual encoding of the RFC 3126 message is not so critical privacy. This encoding is important to interoperability and it is important that it be done to support the various vendor libraries (e.g. MS Cryptoapi, bouncycastle, etc.)
In the Microsoft world the signature creation is using their CryptoAPI. A little more difficult and is in C, but there are some good examples available. Our C toolkit has examples if you would like.
regards, Rick
Company I work for charges 50 cents for the first timestamp. Pricing is here: www.digistamp.com/FAQts.htm#cost We don't have a concept of expring after a year. We have been able to reduce the prices every year for the past 4 years as customer base grows. I agree, the price needs to be less. But, the operations, development and NIST certified hardware, etc. has some cost. Our hope is that as more users convert from paper based processes they will use digital time stamps. With volume our prices will be less - pennies. I expect this price in 2 years. Sorry if this sounds like a company sales attempt. The Java, C, .NET toolkits are no charge.
Can you tell me where you read that the USPS is trying to patent this process? As background, the time stamp protocol is in IETF RFC 3161. The combination of time stamp with signatures is in RFC 3126 "Long term electronic signaures" (includes multple signature, commitment qualifiers, signing comments, etc). The company I work with has made the assumption that these standards would be the basis for the presentation of binding signatures. (www.digistamp.com) There is ongoing work at OASIS as they work on the XML versions of these protocols. The standards involve both protocol and process. There is still the process of CA related to associated an individual to a public key. There are several of these in practice and often involve a step of using a notary. It has been interesting of the past few years in the timestamp business to see how the concept of a notary varies from country to country. Anyway, can you tell me where you read that the USPS is trying to patent this process? Thanks