This solution is safe to access to user's priv

Question

We are developing a web page that use https protocol (two way).

We need to access to the private certificates of the user, because we need sign documents by the user's certificate, so we developed a Java application that communicate with the web by a websoket.

This application will call with a protocol call since the web (same that when you open a pdf on Acrobat Reader from a browser).

So we have to be sure that our web is calling to the native application(only our web). We want develop a system to be sure of that. Our idea:

1. Send a public key, a signed token by the server's private certificate and a symmetric key (to encrypt websocket communications) to the native application.
2. Next, we will Check in the native application that the token it is OK with a web service to the server.
3. After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.
4. Then sent document to the server.

Is this implementation safe? We will be safe of a man in the middle?

Any suggestion about this solution will be wellcome, because I don't see any weakness but I am not an expert on security.

I know other solutions for this problem, like applets, JavaFX or native messages on Chrome, but I only want to know if these solution is safe.

Thanks to all in advance and sorry if my english isn't the best :P,

Answer 1

I see the following issues

1. Send a public key and a signed token by the server's private certificate to the native application.

You are calling a local app by protocol. For example mylocalapp://sign?securitytoken=.... You do not control which application is installed on local PC to respond to mylocalapp://. The browser shows an ugly warning because you are leaving the secure environment. An attacker could have replaced the default app, simulate the flow and get all signed documents.

2.Next, we will Check in the native application that the token it is OK with a web service to the server.

To verify identity of server and avoid a ManInTheMiddel attach you need also to set a trustore for your application with the server certificate

Your server needs also to verify identity of client. Are you planning to use TLS two ways also?

3. After, we will have to open the websocket between the native app and the web, and send the signed document by the native app by this way.

You do not need a websocket. Simply use a URL connection to download and upload the documents.

---

This solution was used by Spanish ministry of economy when chrome decided to cut the NPAPI support and signature applets began to fail. Now, they have rebuilt the system in this way

1. Install a local Java application on the user's PC. The application listens on a port as, for example 5678

2. In your page, javascript connects to the application in the form http://127.0.0.1:5678/sign and sends the data to sign.

3. The application is local and has no trouble using the operating system keystore, which includes drivers PKCS#11. Perform digital signature and sends the result to the server

4. The javascript of the page periodically query the result and retrieves it when ready

The security problem is basically the same, but install a server in localhost is harder than replace the local default app.

The solution is called @firma, I guess you probably know it. It is opensource, you can use it