2

My ques is -- Is it possible to digitally sign a hash value of a file directly instead of file.

I have to digitally sign a xml file in web environment through e-token. So I have to download the file from server to client and then get certificate from e-token usb at client machine and sign the file and upload it on server.

But the problem is, if size of the file is too huge, then it will take too much time to download at client side (depend upon internet speed) and some leakage in the security of the file too.

So instead of sending file to client machine, send only file hash value (internally hash value of files are signed not files as general flow of digitally signature process).

Or is there any other alternatives solution ?

Ankit Sharma
  • 1,569
  • 3
  • 19
  • 31
  • Can't you just create a meta data file and sign that? To verify the file authenticity you can use a hash. But that may not be an option if you don't control the verification process. – Thihara Sep 10 '13 at 07:05
  • Then one addition file I need to maintain for each file and for verification process I need to verify that additional file instead of original file. Then it will not fulfill the constraint of digital signature. am I right? Please correct me if I am wrong. – Ankit Sharma Sep 10 '13 at 07:56
  • Yes but if you are verificating between two internal apps I think this is a possibility. Only option I think of is to upload the e-token to the server and do the verification there, the reverse of what you are doing... – Thihara Sep 10 '13 at 08:32
  • No, e-token can't b upload to the server because of hardware restriction but Verification between too apps might b a solution. Thanks – Ankit Sharma Sep 10 '13 at 09:02
  • Don't use e-tokens! Centralized PKI signing solves all of these issues. – Larry K Sep 10 '13 at 17:52
  • @LarryK and makes the whole concept of personal signing void. And don't forget about non-corporate environments. – Eugene Mayevski 'Callback Sep 11 '13 at 15:57
  • @LarryK more security issues we need to concern in this approach – Ankit Sharma Sep 12 '13 at 05:14

2 Answers2

1

@Eugene brings up some valid points about the details of securely passing the hash.

Since you have an eToken, you could use it to establish a 2-way SSL session between the client and server. This session could be used to transfer the hash to the client, and the resulting signature back to the server.

For signing a hash on the client side in Java, you could use a Signature algorithm like NONEwithRSA instead of one like SHA256withRSA.

"NONE" specifies that the raw data (in this case the hash) will be signed and not hashed again by the algorithm.

gtrig
  • 12,550
  • 5
  • 28
  • 36
  • Thank you for ur suggestion, but it will generate only SignatureValue, but not sign-info and key-info elements (as in xml digital signature api). So we have to generate those element manually for each file ? – Ankit Sharma Sep 11 '13 at 09:58
  • When I used NONEwithRSA, it returned CKR_FUNCTION_FAILED – hienbt88 Jan 20 '14 at 06:46
  • @hienbt88 which signing algorithms actually are available via the JCE/JCA API may be implementation dependent; that been said, have you made sure that the hash value is properly encapsulated and that correct padding is applied, and furthermore that those steps did not happen twice? – mkl Jan 21 '14 at 08:34
0

Well, it is of course possible to pass the hash to the client and sign it there, but the devil is in details -- in case of such distributed signing you need to design a really secure way to pass the hash and the signature and to sign it securely on the client side. Also you need to have the code on the server that will let you calculate the hash, pass it to the client and then embed the signature to the signing format of your choice.

Our company has developed a Distributed Cryptography add-on to our SecureBlackbox product that addresses all of the above problems. For details you are welcome to check this answer on StackOverflow.

Community
  • 1
  • 1
Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Thank you for ur suggestion,The environment that u have explained in the given link, I m following the same but instead of sending the hash, i m sending files directly and using applet to sign the files. This product is open-source ? will it work for XML file too ? I need only one part of this process to make it more secure, otherwise i have done. – Ankit Sharma Sep 11 '13 at 09:59
  • Sending a hash is not a problem, dealing with it on both sides properly and securely is. And this can not be explained within SO comment. SecureBlackbox deals with various files including XML (and offers XMLDSig and XAdES support). And no, this is not open-source, sorry - good work costs money. – Eugene Mayevski 'Callback Sep 11 '13 at 15:46
  • Yes this thing I also know that signing a hash is not a problem, but if we ll sign a hash of a file instead of file, then during verification process, also we need to add some extra logic too. – Ankit Sharma Sep 12 '13 at 05:13
  • Is there any security risk or integrity problem when signing a hash value instead of a file? – hienbt88 Jan 20 '14 at 06:49
  • @hienbt88 It's always the hash that is signed, not the complete file (the latter is not technically possible). The question is how to ensure that the hash belongs to the file, and this problem is especially important in case of distributed signing. – Eugene Mayevski 'Callback Jan 20 '14 at 08:14
  • Thanks but I mean when the hash value is hashed again and signing this second hash. – hienbt88 Jan 20 '14 at 08:20
  • @hienbt88 The whole process is very simple. You have to send the hash value of file to client side in the form of string and u hv to maintain this hash value at server side too for verification (temporarily). Then sign this hash value and return the result to server. Now at server side get the resultant value and get the original value through public certificate out of resultant value and compare the output of this process with stored hash value. If both are same then everything is fine otherwise in middle some problem happened, u hv to repeat the whole process again. – Ankit Sharma Jan 20 '14 at 12:32
  • @AnkitSharma This "simple" scheme has several obvious flows and attack vectors. – Eugene Mayevski 'Callback Jan 20 '14 at 12:35
  • @EugeneMayevski'EldoSCorp Yes of course, thts y "verification" steps are thr. – Ankit Sharma Jan 20 '14 at 12:49
  • @hienbt88 *when the hash value is hashed again and signing this second hash* - extra hashing is not required in the OP's case, merely the place where the hash is generated changed. That been said, extremely often in the context of CMS signatures you do double-hash: you hash the document data, then build a collection of attributes to be secured (the hash among them), and finally sign (i.e. essentially encrypt the hash of) this structure. – mkl Jan 21 '14 at 08:27