(continuing top posting to keep thread consistent)
Note that the point of using an X.509 signature at file creation time
and/or client approval time was to reuse the internal file structure
that is already designed to hold that particular signature format
(specifically, the internal file structure that would eventually hold
the final signature, which was already specified to be in that format).
Thus the idea was to simplify and reuse code, given the existence of
code, tools and data formats to sign those particular files with X.509
signatures. This was also (presumably) the reason Microsoft did it this
way.
But yes, of cause if the file generation is already secure, then the
secure file generation machine should apply an initial signature and the
client just add some kind of counter-signature authorizing this
particular one of the securely generated files.
On 24/06/2015 15:24, Michael Wojcik wrote:
In Marco's original description, the file is created by a trusted
system and then transmitted to the client. Then, later, the client
transmits it to the server, which verifies the contents. If the file
is signed by the creating system, it doesn't matter if the client is
compromised. A compromised client can refuse to send the file, or it
can send a forged or corrupted file, but the server can dectect all of
those cases.
It's not clear from Marco's description whether the system that
creates the file can perform the signing process, but I don't see any
reason (in the description) why not. It would help if this point were
clarified.
The Windows driver-signing process and similar look wildly
overengineered for Marco's purposes, if my understanding of his
requirements is correct. They have a very different threat model - and
that's why this isn't "a common requirement". Windows drivers are
created by thousands of organizations and consumed by thousands of end
users. Marco has files created on a trusted system (or handful of
trusted systems) he controls, and verified by trusted systems he controls.
His followup message below says "data has to be signed with an X.509
certificates public key that already exists". I'm guessing this
actually means "data has to be signed with the private key
corresponding to a public key that happens to be in an X.509
certificate that already exists". That doesn't mean X.509 PKI must be
used; X.509 isn't some sort of virus that infects everything it
touches (appearances to the contrary). There's an asymmetric key pair
of some sort - RSA probably - and we need to use it for signing. Fine.
Here's what I'd do: the originating trusted system creates the data
and runs "openssl rsautl -sign" with appropriate parameters to create
a signature. (Just script the openssl command-line utility; this is a
trusted system, so why reimplement the code?) Add the signature to the
proprietary file format. Send the whole thing to the client.
Client subsequently sends the signed data and signature to the server,
as part of a file in the proprietary format, along with whatever
unsigned data is included.
Server extracts the signed data and signature, and uses "openssl
rsautl -verify" to verify it.
Michael Wojcik
Technology Specialist, Micro Focus
(original text snipped)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
