[openssl-users] beginner needs advice on data signature/verification

Tue Jun 23 17:55:02 UTC 2015

Many thanks for the answer.

I should have been more specific on the requirements right away. The 
"file" was really just an example to keep it simple. Reading my own 
writing, I would probably have suggested what you did :-)

So here are the facts:
- client/server are not connected to the internet
- the network protocol is existing and proprietary
- the file structure is existing and proprietary, but can be extended to 
allow for additional signature information to be embedded that will be 
sent to the server
- the data actually transferred (and to be signed) is part of that file
- the data has to be signed with an X.509 certificates public key that 
already exists

S/MIME does pretty much do what I want to do. However the network 
protocol or the data to be signed cannot be changed for compatibility 
reasons. Under these circumstances, I don't really see how I could 
achieve my goal easier than by openssl directly.

Considering the "very common requirement": I was thinking of i.e. 
windows driver signatures, android/ios app signatures and similar 
mechanisms to ensure that files are from a trusted source.

Am 22.06.2015 um 14:44 schrieb Michael Wojcik:
>
> Response inline below, prefixed with "MW". (Unfortunately Outlook is 
> incapable of replying to HTML messages properly, so you'll have to 
> excuse the formatting.)
>
> Michael Wojcik
> Technology Specialist, Micro Focus
>
> *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On 
> Behalf Of *Marco Warga
> *Sent:* Saturday, June 20, 2015 04:48
> *To:* openssl-users at openssl.org
> *Subject:* [openssl-users] beginner needs advice on data 
> signature/verification
>
> Hi,
>
> I hope some of you could give me advice on my project using openssl.
>
> MW: Why are you using OpenSSL for this application? You want to create 
> a file on a trusted system, pass it through an untrusted intermediary, 
> and process it on another trusted system. Why not simply use an 
> existing mechanism like secure email? (GPG is the obvious choice, 
> unless there are licensing issues.) If you are determined to create 
> your own protocol from primitives, then really all you appear to need 
> here is an HMAC. Don't involve the horrific mess that is X.509 PKI 
> unless it actually provides some benefit.
>
>
> Lets say I have a server/service on a machine processing a file a 
> corresponding client sends. That file is usually created by me on a 
> clean third machine. The server side is assumed to be uncompromised 
> (no hacker). The client side may be compromised. Now I need to make 
> sure that the service only accepts those files that are created by me. 
> I believe that is a very common requirement and has been done alot of 
> times - I just can't find tutorials on how to implement it. Know any ?
>
> MW: No, but that's probably because what you've described isn't "a 
> very common requirement". It's too vague. We don't know what problem 
> you're actually trying to solve. It may be that you just need to send 
> a file with a verifier, which - as I noted above - /is/ commonly done, 
> generally using something like GPG or (for roll-your-own protocols 
> where both ends are controlled by the same party) an HMAC.
>
>
>
> Lets assume I have an x509 cert together with its private key signed 
> by a ca owned by me. The trusted ca cert will be present on the server 
> side. This is what I plan to do:
>
> 1.) Create the data files/blobs and sign them using the priv key of 
> the cert. Distribute the cert and the signature along with (or inside) 
> the data file.
> 2.) Have the client send that data file to the server (cert/sig first)
> 3.) Service receives the cert, builds a cert store with the local ca 
> cert in it and verifies the client's cert with X509_verify_cert()
> 4.) if cert verifies ok, service compares the signature against the 
> one calculated from the incoming data using the public key that came 
> inside the cert just verified
>
>
> Would this be the right approach considering that anything the client 
> sends may be forged (cert, sig, data...) ?
>
> MW: It's safe from malicious behavior by the client, under a threat 
> model where an attacker is not able to forge client certificates or 
> client signatures. In other words, it's safe as long as the private 
> keys are neither leaked nor forced.
>
>
> Or would it be safer to have the cert used for signing stored on the 
> server side and not send with the data (instead just its subject 
> protected by the signature) ?
>
> MW: Irrelevant to the security of the scheme. Simpler from a 
> development and operations standpoint. But using something like 
> PGP/GPG or S/MIME would be simpler yet. There are any number of 
> examples online for signing a file and verifying its signature.
>
>
>
> Thanks alot,
> Marco
>
> X509_verify_cert
>
> X509_verify_cert
>
> Click here 
> <https://www.mailcontrol.com/sr/SMsSvn1riRfGX2PQPOmvUsrLibhXE7+S86glxWVUEjKk%21XLlG9uNumpG1wkqEL+kqdX9II%21hjWj1JTd%211uc+%21w==> 
> to report this email as spam.
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150623/a62f8771/attachment-0001.html>