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-boun...@openssl.org] *On
Behalf Of *Marco Warga
*Sent:* Saturday, June 20, 2015 04:48
*To:* openssl-users@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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
