I have a project to generate PDFs on a server using ASP.NET (C #). But now we need the customer to be able to digitally sign these PDF. From what I saw, the documents must be signed at the client side, using an applet, as in the server I have no access to the private key of the certificate, but as I said above, the PDFs are generated on the server and I keep them there.
So, what I need is to digitally sign PDFs on the server, taking the client's certificate.
Thanks
Since it is not possible or anyway safe to extract and send the client's private key, to sign pdfs on the server you need to establish a "session" with the client and let them calculate the signature.
The steps should be something like:
the client sends his public certificate to be embedded in the signed pdf
the server generates the pdf, embeds the certificate and calculates the hash (eg: sha1)
the server sends the hash to the client applet
the applet calculates the digital signature with her private key
the applet sends the signature to the server
the server embeds the digital signature and closes the pdf.
To do this with itext you will have to use the preclose method after ambedding the certificate, so to be able to alculate the sha1 hash on the final document.
Then after pre-closing the pdf you will have to calculate the hash of the pdf and send it to the client.
Be careful: while preclosed you will have to keep the document in memory, for example in a server session.
To generate the pdf, embed certificates and prepaare the document you can use itextsharp, the c# port of the itext library. To calculate the hash and create the pkcs7 envelopes you can use the .net crypto api.
Hope this helps.
You might be missing the point of digitally signing a document. The act of signing a document is meant to be a user activity.
You can create the document on the server side and serve it with the content-type "application/pdf" and that will serve the document to be signed. When they sign it you can use pdf form submit to submit the signed document back to the server.
AspPdf + USB Network Gate or AnywhereUSB might help if the client uses USB smard card on their machine.
you can also use a signing service like (I'm sorry, I just know this one as working) http://www.signagate.de - these guys offer an Web service that enables you to 'upload' an unsigned pdf which will be sent back with an so called 'intermediate' signature that is conforming to even all signature laws in the EU as a qualified signature (at least for invoices as I know).
The fun is, you just need to be able to do a post call to their service to get the pdf singed back as answer.
So the 'intermediate' thing allows you (from a legal view) to NOT promote the private key etc. around the world but getting a valid signature on your PDF and keeping so the legal needs by a proper authentication to the signature service of this company.
Jimmy
Related
I'm implementing 2FA on my app with phone number verification. As SMS are not free, I really need to ensure that a request to my server comes from my app and not from any third party http request launcher.
For this purpose, I thought about encrypting the http request with a key provided by my server within my app, and send that encrypted request. As my app is a binary (this is not applicable for web of course), I was thinking it would be difficult to see the encrypting method. The process would be the following :
my app asks my server a key
my server generates, stores and returns a random key
app encrypt the whole actual request with a "secret" method, depending on that key (secret = in binary so hardly readable)
app send to server the encrypted request + the key
The server sees if the key exists, and tries to decrypt the request. If it manages to decrypt, it proceed the request, and then remove the key from its storage so no one can use it anymore.
I don't see any to compromise this system, except if someone manage to read from apple/android binary app the encrypting system the app uses.
Do you think this can be a good process ? Do you see any way to compromise this system ? Is reading from a binary file is really difficult ?
I will start with the flaws in your design, from an android perspective, even if you have enabled pro-guard for your app, we can still decompile the app and trace back the api calls
If your server is not using HTTPS - its easy to trace the calls going
back to the backend server by routing through a proxy server like
charles proxy, and analysing the response, even if you are using
https its possible to install ssl certificates to trust the proxy and
get the response. Also by analyzing the outbound requests its
possible to extract the signed key from the app
Its easy to decompile an apk package and opening it in IDEs and
searching for the backend server url by inputting 'api' or
'http','https' keywords on the ide project search window
If you are storing the secrets in shared preferences or storage, it
can be read from the device ,if the attacker has root access to file
system.
then remove the key from its storage so no one can use it anymore.
For the above scenario, i will run the app and once it stores the key , i can change the permission to read only , so even if the app tries to remove it , it wont be deleted
You can use SSL-Pinning, and putting the keys in compiled libraries making it difficult for the attacker to decrypt the key, also you need to make sure that you don't create any other loop holes
You may also share the common key between app and server through alternate channel , like an email . Where the user once he registers for the App gets and Email with a QR code which once scanned will give the server key. The security of this approach is tied to the secure access of the email by authorized user.
You may them follow the standard approach of sending the encrypted request to server to verify the phone number , once done you may delete the data form your app storage.
I want to build an app where users upload files. But the owners of the server should never be able to have access to any data from the files, only encrypted content.
If I had to implement it myself using Java, I would do something like:
symmetric encryption for the files using a random key per file (or per user because I don't need per file access control). The random key is then asymmetrically encrypted (one time for each user needing access to the file) and stored along the file on the server
Users have a password encrypting their randomly generated on account creation private key stored on the server along with the public key.
The user password hash (not the password itself) is also used as an authentication password to avoid having multiple passwords but also to avoid sending the user password to the server (the server then normally computes and compares the salted hash of this hash of the password)
How can I implement a custom app like this (using libraries?, running additional servers with http APIs?, something else?) ?
I found https://www.minio.io/features.html, an http server with s3 compatible rest APIs which has "Both server side and client side encryption are supported" but couldn't find enough documentation on the client side encryption.
If I want to encrypt data on a server, and send it to a client program which I have implemented and sent to the customer, is there anyway that I can store the decryption key and algorithm in the client program, without risking that reverse engineering my client program will enable the user to decrypt all the data I send.
That is, I want my client program to control what it decrypts and what not.
Thanks
Jeeji
You can hard-code the algorithm with no risk. The security must be based in the secrecy of the key, not of the algorithm.
To secretly store the decryption key, you can use a keystore.
I don't know which language you are using, but Java includes its own keystore, and for C you get a keystore through NSS. To open these keystores you will need a password that the user can type in when the client application starts up.
If your client runs on linux and gnome, then you could also use Gnome's keyring, in which case the user will not need to type the password to open the keyring (the log-in password is also used to open the keyring).
I have an asp.net mvc web application with some customers.
A new customer tells me that its data should be crypted on its client and then sent to server (that will store the data into database).
When the client will request the data, they will be read from db and decrypted on client side.
As is, only he will be able to display the correct data.
I found another post, but i need some samples.
Can i make it with javascript?
How it works? javascript read the private key from a certificate on client machine?
How could you encrypt user data so only they can decrypt it?
tks
Public Key Encryption with Javascript:
http://shop-js.sourceforge.net/crypto2.htm
Keep in mind that you can't read local files with javascript alone. You might need to have a Silverlight app running on the client-side as silverlight can read local files. Maybe have your login screen done in Silverlight?
http://www.insidercoding.com/post/2008/08/17/Reading-Local-Files-in-Silverlight.aspx
In my application, the client must sign (using a certificate) and send data to the server.
My doubt is how should I do it?
To sign on the client side, I should use ActiveX right? My problem is that firefox doesn't support it.
Signing on the server side I have two options:
Save the private key on the server and use it when necessary (if the data is modified during the transaction it will sign false data)
Send the private key when necessary (may comprise the key)
Despite using SSL, I'm not very confortable with any of the two options for signing on the server side...
Using ActiveX may cause my application more vulnerable, right?
Hope you can help me :)
There's no single solution for client-side signing in all browsers, unfortunately. We are currently working on distributed signature components for our SecureBlackbox product, and we've created Java applet, ActiveX control and Flex script to perform signing. However, all variants have shortcomings. For example, only ActiveX control can access windows certificate store. With other module types the user would need to load the certificate from PFX (PKCS#12) file.
Uploading and signing on the server won't work because the private key is not always exportable on the client (it can reside on cryptotoken or smartcard, or just be non-exportable), and also this approach makes the whole process useless as it significantly lowers security.
Update: SecureBlackbox 9 is in public beta now, with support for client-side signing (we provide ActiveX, Java and Flash modules for this).