[openssl-users] beginner needs advice on data signature/verification
watz at watz.at
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
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
> 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,
> Click here
> 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...
More information about the openssl-users