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>
