<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
<p>(Continuing top posting to keep thread consistent).<br>
</p>
<p>First of all, if the client itself is compromised, the file
content can be compromised just before you do whatever you do to
assure the server that this was what the user of the client
wanted. No way to fix that other than to keep the client free
of compromise.<br>
</p>
<p>Now the common solution used by driver and program signing
programs such as Symbian signed (discontinued), Windows driver
package signing for compatibility, Windows driver binary signing
for Windows 10, and older versions of Windows Mobile 5.x/6.x
signing is this:<br>
</p>
<ol>
<li>Client has a unique X509 certificate with a private key
known only to that client. Doesn't matter who issued the
certificate, but the server needs to have its own known
genuine copy of that certificate. That certificate should be
such that no one except that client and that server trusts
things for being signed by it.<br>
</li>
<li>Client signs the file/message with its private certificate
exactly as if that would be the final signature (even though
almost no one will trust it).</li>
<li>Client sends signed file/message to server.</li>
<li>Server verifies the signed file/message using its private
list of trusted client certificates.</li>
<li>Server maps the verified signature to the identity to be
used for the final signature.</li>
<li>Server talks to its closely related CA to get a brand new
single-use-only certificate for the identity (with a serial
number added as an extra subject name element).</li>
<li>Server removes the client signature and signs the
file/message with the brand new certificate for the final
identity.</li>
<li>Server throws away the private key, so that no more files
can be signed with that certificate, ever.</li>
<li>If the server ever signs anything by mistake, it (or an
admin if the server was permanently compromised) asks its
closely related CA to revoke the affected single-use
certificate.</li>
<li>If the client certificate needs to be revoked due to the
certificate or its user being compromised on some current or
past time/date, the related CA revokes all the single-use
certificates for that identity since that date/time.
Other/replacement client certificates for the same (visible)
identity remain valid because single-use certificates for
those requests were never revoked.</li>
<li>Note that in this setup, there is no need for a time
stamping service, simply give the single-use certificate the
long (listed) lifetime, and rely on the uncompromised server
diligently deleting the private key within a few seconds after
creating it.</li>
</ol>
<p>Of cause you don't need to make this entire "temporary
certificate" dance (steps 6, and 8 to 11), for instance if the
server will be using certificates issued by one of the
pay-per-certificate public CAs, the server will instead need to
keep around a certificate/private key pair for each public
identity, and may need to use a public time stamping service
just as if it was a normal direct end-signer.<br>
</p>
<p>As for the format, putting S/MIME aka CMS aka PKCS#7 format
signatures inside a file format, look at how Microsoft did this
with its AuthentiCode concept and how Sun/Oracle did with its
jar format. Its almost the same procedure with 5 minor
differences:<br>
</p>
<ul>
<li>AuthentiCode sets the PKCS#7 content-type to an AuthentiCode
specific OID, jar file use the generic "data" OID. At least
some members of OpenSSL team suggest that using any OID other
than "data" is not allowed by more recent versions of the CMS
standard.</li>
<li>AuthentiCode signs a custom DER encoded ASN.1 structure with
the relevant attributes and secure hashes of the parts of the
signed document that don't depend on the value/size of the
signature blob itself. Jar signs a formatted text file with
that same data.</li>
<li>(classic) AuthentiCode uses the original countersignature
format and attribute for timestamping, requiring a
timestamping service that creates "bare" signatures of the
small blob sent for timestamping, jar files may or may not use
a slightly different format allowing use of the newer
RFC-based timestamping protocol.</li>
<li>Some implementations of jar signature validation (most
notably the one used by Mozilla/Firefox/Thunderbird) requires
the certificates to have the attributes of the historic
"object signing" protocol, AuthentiCode and most other jar
implementations simply require the relevant extended usage
attribute in the end certificate. Commercial code/object
signing certificates tend to include the extra attributes to
work for both.</li>
<li>The two formats sometimes forget to check different obscure
parts of the file being signed for some file formats. I won't
elaborate on which ones.<br>
</li>
</ul>
<p>From this list of differences and similarities, it should be
somewhat easy to make sane choices for how to design your own
use of X.509 certificates. Note that if the items being signed
are documents rather than program-like objects, you should
probably check for the e-mail signing or document-signing
extended usage attribute, not the object-signing one.<br>
</p>
<br>
On 23/06/2015 19:55, Marco Warga wrote:<br>
</div>
<blockquote cite="mid:55899D76.2060706@watz.at" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Many thanks for the answer.<br>
<br>
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 <span
class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
So here are the facts:<br>
- client/server are not connected to the internet<br>
- the network protocol is existing and proprietary<br>
- 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<br>
- the data actually transferred (and to be signed) is part of
that file<br>
- the data has to be signed with an X.509 certificates public
key that already exists<br>
<br>
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.<br>
<br>
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.<br>
<br>
Am 22.06.2015 um 14:44 schrieb Michael Wojcik:<br>
</div>
<blockquote
cite="mid:B550B44BF8AF314BB00C4E2AC1C18088014C2E2F3A@Rock-Exchange1.microfocus.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
p.code, li.code, div.code
{mso-style-name:code;
mso-style-link:"code Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:Consolas;
color:black;}
span.codeChar
{mso-style-name:"code Char";
mso-style-link:code;
font-family:Consolas;
color:black;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Response
inline below, prefixed with "MW". (Unfortunately Outlook
is incapable of replying to HTML messages properly, so
you'll have to excuse the formatting.)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
openssl-users [<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="mailto:openssl-users-bounces@openssl.org">mailto:openssl-users-bounces@openssl.org</a>]
<b>On Behalf Of </b>Marco Warga<br>
<b>Sent:</b> Saturday, June 20, 2015 04:48<br>
<b>To:</b> <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:openssl-users@openssl.org">openssl-users@openssl.org</a><br>
<b>Subject:</b> [openssl-users] beginner needs
advice on data signature/verification<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
I hope some of you could give me advice on my project
using openssl.<br>
<br>
<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><br>
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 ?<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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 - <i>is</i> commonly
done, generally using something like GPG or (for
roll-your-own protocols where both ends are controlled
by the same party) an HMAC.<o:p></o:p></span></p>
<p class="MsoNormal"><br>
<br>
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:<br>
<br>
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.<br>
2.) Have the client send that data file to the server
(cert/sig first)<br>
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()<br>
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<span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><br>
Would this be the right approach considering that anything
the client sends may be forged (cert, sig, data...) ?<span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><br>
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) ?<span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><br>
</p>
</div>
</div>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
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 </pre>
</body>
</html>