Code signing in OpenBSD

On Dec 6, 2007 2:46 AM, Rui Miguel Silva Seabra <rms@...> wrote:
> Come on... twice a year and get the benefit of not being excluded from
> company policies which require digital signature of software downloaded
> through the internet.

It's not really OpenBSD's problem that some companies implement pointless
"security" policies.

---
Lars Hansson

[Otto Moerbeek]

On Wed, Dec 05, 2007 at 07:02:03PM -0800, Claus Assmann wrote:

> On Wed, Dec 05, 2007, STeve Andre' wrote:
> > On Wednesday 05 December 2007 18:22:19 Claus Assmann wrote:
>
> > > Someone actually did the former with sendmail.org (to distribute a
> > > version of sendmail with a backdoor).  The problem was only noted
> > > because users checked the (digital) signature.
>
> > You know, you're descending into a recursive loop of "if, if, if..." and
> > it never ends.  OF COURSE if someone breaks into the site they could
> > do things--once you've lost control of your site all bets are off.  I dare
>                                                    ^^^^^^^^^^^^^^^^
>
> Hmm, did you read what I wrote?
>
> The breakin was detected due to the digital signature.
>
>
> Anyway, it's obviously up to the OpenBSD developers what they do.

Code signing has it's use, but it does not come for free. It's quite
involved. As always, the key problem is key management, not the
signing itself.

As an illustration, read what I wrote when similar questions came up 5
years ago, and dont forget Dug Song's answer to my post.

<http://marc.info/?l=openbsd-misc&m=103769360002468&w=2>

        -Otto

[Martin Schröder]

2007/12/5, Marco Peereboom <slash@...>:
> have you ever wondered why openbsd doesn't do binary updates?

And what are package updates?

Does pkg_add -u even check an e.g. md5 or does it trust the server?

Best
   Martin

[Rui Miguel Silva Seabra]

On Wed, Dec 05, 2007 at 02:23:41PM -0600, Marco Peereboom wrote:
> blah blah blah
>
> have you ever wondered why openbsd doesn't do binary updates?

I'm not talking about updates, I can read C.

> maybe you are now going to be able to figure out why we don't need
> complex signing mechanisms.

You're ignoring that it is perhaps quite insane to expect anyone to
verify every single line of code, and a (so far very much deserved)
trust is given to the developers. Which is why I would very much like to
be absolutely sure the CD I bought brought the release the developers
intended to publish.

This is not about downloading OpenBSD, but of having a quite measurable
degree of trust that what you have is what you were supposed to have.

Btw, it would be much better to use a hashing algorithm stronger
than MD5, even on the file signed by an OpenPGP or X.509 certificate.

Rui

--
Wibble.
Today is Setting Orange, the 48th day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

[Rui Miguel Silva Seabra]

On Thu, Dec 06, 2007 at 12:37:19PM +0800, Lars Hansson wrote:
> On Dec 6, 2007 2:46 AM, Rui Miguel Silva Seabra <rms@...> wrote:
> > Come on... twice a year and get the benefit of not being excluded from
> > company policies which require digital signature of software downloaded
> > through the internet.
>
> It's not really OpenBSD's problem that some companies implement pointless
> "security" policies.

I'm not discussing wether its pointless or not, maybe you don't want
OpenBSD to be used at all?

Rui

--
Grudnuk demand sustenance!
Today is Setting Orange, the 48th day of The Aftermath in the YOLD 3173
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

[Hannah Schroeter]

Hi!

On Wed, Dec 05, 2007 at 12:15:01PM -0500, bofh wrote:

>On Dec 5, 2007 11:46 AM, new_guy <byte8bits@...> wrote:
>> Can you dismiss PKI and the benefits that OpenPGP signatures provide to your
>> user community? Knowing that xyz binary is signed by OpenBSD for
>> distribution or abc email came from an official OpenBSD source is a good
>> thing. Trojaned binaries and forged emails happen. PKI can help mitigate
>> this. The benefit of PKI is widely known and accepted and does not need to
>> be rehashed here. I'm surprised that OpenBSD (the most secure OS I know of)
>> does not use it, that's all I'm saying. I also thought there would be a real
>> reason for not doing so and there may in fact be and I may just be unaware
>> of it.

>What are the risks you are trying to address?

One risk would be the plans of "online surveillance" of computers e.g.
in Germany. One way to install surveillance even on OpenBSD would be to
actively interfere with the internet connection with the surveilled
person, in the man-in-the-middle sense, and inject trojanned code
("Bundestrojaner") into the updates of the victim.

Using OpenBSD CDs doesn't protect the victim from attacks like that
that much because many people need ports/packages and to get fixes one
virtually has to use -current most of the time, and to update -current,
one often uses snapshots over non-secured transfers (ftp, rsync, source
via cvsync/cvsup). The only exception I know of is anoncvs via ssh,
but then, the CDs, IIRC, don't even ship with a known_hosts file for
the anoncvs servers.

As the talk about those "online surveillance" plans includes talk about
tailored attacks for each victim, they could investigate which OS one
uses and which ways of updating, so they could tailor their attack
vector appropriately.

Yes, *I*'d be vulnerable. I'd be not if I had a public key (and anoncvs
known_hosts file) from CD, perhaps also cvsync with cryprographic
integrity protection and public key (fingerprints) from CD, etc.

So the "online surveillance" stuff would perhaps not only affect Windoze
boxen as some people would come to think, even though the installation
of a trojan is, of course, usually much easier for Windoze than for
OpenBSD (or even a Linux installation if people with some skills operate
them).

Yes, of course cryptographic integrity protection wouldn't secure
OpenBSD against all kinds of attack vectors, but against *some*. Yes, it
comes at a cost. And I don't know whether the cost is really worth
while...

But I question whether it's really sound to just dismiss it beforehand.

>[...]

Kind regards,

Hannah.

[Hannah Schroeter]

Hi!

On Wed, Dec 05, 2007 at 01:24:49PM -0700, Bob Beck wrote:
> If you want a secure binary. buy an official CD.. This is
>what most people do.  PKI requires infrastructure that would cost OpenBSD
>money and developer time. Official CD's keep OpenBSD alive.

Doesn't help you if you want fixes for ports/packages or even the base
OS. Once you want that, you have to update over the net, and as I said
in my other mail, here you have no clear protection. Or do the CDs at
least carry a known_hosts file for the anoncvs servers, inbetween?

>[...]

Kind regards,

Hannah.

[Hannah Schroeter]

Hi!

On Wed, Dec 05, 2007 at 06:46:15PM -0500, STeve Andre' wrote:
>[...]

>You know, you're descending into a recursive loop of "if, if, if..." and
>it never ends.  OF COURSE if someone breaks into the site they could
>do things--once you've lost control of your site all bets are off.  I dare
>say that someone breaking into a site might find all the appropriate
>tools to re-sign things, too, and do the spoof that way.

If I released code with cryptographic signatures, I'd not leave a secret
key file, nor a passphrase on the servers with the master web/ftp
site. I'd sign on a box you can't access from the master site (nor
the mirrors). So, no, the attacker would *not* gain access to signing
tools (ok, yes, the tools, perhaps, like gpg or openssl, but not the
key material).

>--STeve Andre'

Kind regards,

Hannah.

[Lars Nooden]

Hannah Schroeter wrote:
...
> As the talk about those "online surveillance" plans includes talk about
> tailored attacks for each victim, they could investigate which OS one
> uses and which ways of updating, so they could tailor their attack
> vector appropriately.
...

Some of this is mitigated in that when using OpenBSD, the connections to
the repositories is signed.  Though, it looks like HTTP transfers are
not, and there is the question of getting the initial installation
packages.

If the installation process (from the purchased CDs) had a list of the
public keys for the official mirror sites, then that would go a long
way.  Having the installation process pre-load the keys into the data
for the ssh, ftp and afs clients would be even fancier.

-Lars

[Stuart Henderson]

On 2007/12/06 13:12, Lars Noodin wrote:
>
> If the installation process (from the purchased CDs) had a list of the
> public keys for the official mirror sites, then that would go a long
> way.

That would make it rather hard to revoke a key if there ever
was a problem.

[Hannah Schroeter]

Hi!

On Thu, Dec 06, 2007 at 11:23:37AM +0000, Stuart Henderson wrote:
>On 2007/12/06 13:12, Lars Noodin wrote:

>> If the installation process (from the purchased CDs) had a list of the
>> public keys for the official mirror sites, then that would go a long
>> way.

>That would make it rather hard to revoke a key if there ever
>was a problem.

Key revocation lists in some form? If it's gpg/OpenPGP, instruct users
to update from keyservers, one will notice when there're
incompatibilities between the key from CD and the one from the
keyserver, but one will also get the revocation from the keyserver. And
if one buys every CD, there's the time window of half a year even
without a key revocation infrastructure.

Kind regards,

Hannah.

[Hannah Schroeter]

Hi!

On Thu, Dec 06, 2007 at 01:12:02PM +0200, Lars Noodin wrote:
>Hannah Schroeter wrote:
>...
>> As the talk about those "online surveillance" plans includes talk about
>> tailored attacks for each victim, they could investigate which OS one
>> uses and which ways of updating, so they could tailor their attack
>> vector appropriately.
>...

>Some of this is mitigated in that when using OpenBSD, the connections to
>the repositories is signed.  Though, it looks like HTTP transfers are
>not, and there is the question of getting the initial installation
>packages.

Have I missed something? Last time I checked, it was plain http/ftp for
retrieving the base tarballs as well as the packages.

>[...]

Kind regards,

Hannah.

[Lars Nooden]

Hannah Schroeter wrote:
> ...
>> AFS is also encrypted, but unless its used to
>> get all the tarballs and make them accessible locally (e.g. make a cd)
>> it's not a help during the installation.
>
> I don't know enough about AFS to say anything about how to secure it
> from the beginning on.

I'm not very knowledgeable, but have been looking at the documenation
lately:
        http://www.openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ75

> ...
>> Given the existence of Windows servers (aka compromised machines) on
>> many networks, there are many chances for traffic to be intercepted,
>> often even DNS.  So man-in-the-middle attacks appear to be theoretically
>> easy during the first part of an OpenBSD network installation.
>
> Yes, alas. And especially, for government "legal" interception, where
> they could legally enlist help from ISPs.

So, intentional (corporate or government agreement with ISP) or
unintentional (use of M$ on ISP DNS server), could allow the initial
installation to become compromised, perhaps in a hard-to-detect way.

None of this seems to be solved in the installation guide:
        http://openbsd.org/faq/faq4.html

Again, it looks like it might come down to keys or fingerprints and that
the network install might be depreciated.  Rather, download, verify,
then install.

-Lars

[BOFH-5]

At this point, it's probably a good idea to point out there's a paper
called Trusting Trust about your everyday C compiler...


On 12/6/07, Lars Noodin <larsnooden@...> wrote:

> Hannah Schroeter wrote:
> > ...
> >> AFS is also encrypted, but unless its used to
> >> get all the tarballs and make them accessible locally (e.g. make a cd)
> >> it's not a help during the installation.
> >
> > I don't know enough about AFS to say anything about how to secure it
> > from the beginning on.
>
> I'm not very knowledgeable, but have been looking at the documenation
> lately:
> http://www.openafs.org/pages/doc/AdminGuide/auagd007.htm#HDRWQ75
>
> > ...
> >> Given the existence of Windows servers (aka compromised machines) on
> >> many networks, there are many chances for traffic to be intercepted,
> >> often even DNS.  So man-in-the-middle attacks appear to be theoretically
> >> easy during the first part of an OpenBSD network installation.
> >
> > Yes, alas. And especially, for government "legal" interception, where
> > they could legally enlist help from ISPs.
>
> So, intentional (corporate or government agreement with ISP) or
> unintentional (use of M$ on ISP DNS server), could allow the initial
> installation to become compromised, perhaps in a hard-to-detect way.
>
> None of this seems to be solved in the installation guide:
> http://openbsd.org/faq/faq4.html
>
> Again, it looks like it might come down to keys or fingerprints and that
> the network install might be depreciated.  Rather, download, verify,
> then install.
>
> -Lars
>
>

--
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford

[Douglas A. Tutty]

On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
 
> One risk would be the plans of "online surveillance" of computers e.g.
> in Germany. One way to install surveillance even on OpenBSD would be to
> actively interfere with the internet connection with the surveilled
> person, in the man-in-the-middle sense, and inject trojanned code
> ("Bundestrojaner") into the updates of the victim.

Using software from any source without interference from an
all-pervasive government is a very special, but unfortunatly today, a
very real issue for many people around the world.  To be secure, you
have to get pieces of the puzzle over multiple paths.  It all can't come
via the net since then you're open to man-in-the-middle.  

Key-revocation announcements could come over the net (via an announce
list) but the new key would then have to come over a second channel.

One second-channel option is the q6mth CD issue, which could include a
new public key and e.g. known-hosts fingerprints.  This is vulnerable to
a very determined man-in-the-middle who can replicate and then alter the
CD before it arrives to you in the mail.

Another option is a trusted courier flying to Alberta and get a CD from
the OpenBSD store  (yeah, right).

In fact, likely any other technological option (e.g. an answering
machine in Alberta that spits out the alphanumerics of the current
master public key) is still suceptible.

If every piece of information you receive is filter through your
government, is there any hand-shaking protocol that can allow you to
establish a verified information connection (not necessarily encrypted)?
I don't think so.

Sure, Debian has signed .debs that use gpg as a back end (the system is
called apt-key), it relies on you trusting the fist key that you get
from them.  Since Debian doesn't actually mail out its own CDs,
everything is off its mirrors.  apt-key only 'protects' you from a later
man-in-the-middle.

I think that this is the central 'problem' that people are dancing
around.  

Personally, if this thread is to continue, I would like to see it move
from a "Why doesn't OpenBSD do things this way?" to a "What are the
threat models for OpenBSD identity theft and how can we protect
ourselves?".

Doug.

[Marco Peereboom]

hitler already

On Thu, Dec 06, 2007 at 05:24:40PM +0200, Lars Nood??n wrote:

> Douglas A. Tutty wrote:
> > Using software from any source without interference from an
> > all-pervasive government is a very special,...
>
> It's not all about governments.  Corporate espionage is probably a
> larger, more active threat, especially to OpenBSD.
>
> "cui bono?"
>
> If we assume for the sake of argument that the printed CDs are ok, then
> there is at least one method for distributing keys and/or building a web
> of trust.
>
> -Lars

[Lars Nooden]

bofh wrote:
> At this point, it's probably a good idea to point out there's a paper
> called Trusting Trust about your everyday C compiler...

Yeah.  It recently disappeared from the ACM's web site after 11+ years
of availability:
        http://www.acm.org/classics/oct95/
There is, fortunately, the author's copy:
        http://cm.bell-labs.com/who/ken/trust.html

There is an interesting follow up:
        http://www.dwheeler.com/trusting-trust/
summary of the followup:
 http://www.schneier.com/blog/archives/2006/01/countering_trus.html

The bottom line, however, is that having and using the source is not
optional.

Thus, patches are provided in OpenBSD as source...

But, starting from an initial set of some binaries is adequate for many
uses, just as long as we can make reasonably sure that those binaries
come from who they are supposed to / we expect them to.

The install process ought to be fairly clear about the origin,
authenticity and integrity of those initial binaries.  No need to build
on more of a sand foundation than necessary.

-Lars

[BOFH-5]

That's why I always hand enter, in binary, by toggling switches on the
front of my box[1] when I start a new system.


[1]. What, you never pressed the power button


On 12/6/07, Lars Noodin <larsnooden@...> wrote:

> bofh wrote:
> > At this point, it's probably a good idea to point out there's a paper
> > called Trusting Trust about your everyday C compiler...
>
> Yeah.  It recently disappeared from the ACM's web site after 11+ years
> of availability:
> http://www.acm.org/classics/oct95/
> There is, fortunately, the author's copy:
> http://cm.bell-labs.com/who/ken/trust.html
>
> There is an interesting follow up:
> http://www.dwheeler.com/trusting-trust/
> summary of the followup:
>  http://www.schneier.com/blog/archives/2006/01/countering_trus.html
>
> The bottom line, however, is that having and using the source is not
> optional.
>
> Thus, patches are provided in OpenBSD as source...
>
> But, starting from an initial set of some binaries is adequate for many
> uses, just as long as we can make reasonably sure that those binaries
> come from who they are supposed to / we expect them to.
>
> The install process ought to be fairly clear about the origin,
> authenticity and integrity of those initial binaries.  No need to build
> on more of a sand foundation than necessary.
>
> -Lars
>

--
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford

[Lars Nooden]

Douglas A. Tutty wrote:
> Using software from any source without interference from an
> all-pervasive government is a very special,...

It's not all about governments.  Corporate espionage is probably a
larger, more active threat, especially to OpenBSD.

        "cui bono?"

If we assume for the sake of argument that the printed CDs are ok, then
there is at least one method for distributing keys and/or building a web
of trust.

-Lars

[BOFH-5]

You forgot one option.  Invite Theo to give a talk, and ask him to
bring the CDs.  If you can't trust Theo's CDs, all hope is lost.

Just need to make sure there're some mountains around for Theo to go
climb.  If you live on a flatland, then, sorry, you're doomed.


On 12/6/07, Douglas A. Tutty <dtutty@...> wrote:

> On Thu, Dec 06, 2007 at 11:48:55AM +0100, Hannah Schroeter wrote:
>
> > One risk would be the plans of "online surveillance" of computers e.g.
> > in Germany. One way to install surveillance even on OpenBSD would be to
> > actively interfere with the internet connection with the surveilled
> > person, in the man-in-the-middle sense, and inject trojanned code
> > ("Bundestrojaner") into the updates of the victim.
>
> Using software from any source without interference from an
> all-pervasive government is a very special, but unfortunatly today, a
> very real issue for many people around the world.  To be secure, you
> have to get pieces of the puzzle over multiple paths.  It all can't come
> via the net since then you're open to man-in-the-middle.
>
> Key-revocation announcements could come over the net (via an announce
> list) but the new key would then have to come over a second channel.
>
> One second-channel option is the q6mth CD issue, which could include a
> new public key and e.g. known-hosts fingerprints.  This is vulnerable to
> a very determined man-in-the-middle who can replicate and then alter the
> CD before it arrives to you in the mail.
>
> Another option is a trusted courier flying to Alberta and get a CD from
> the OpenBSD store  (yeah, right).
>
> In fact, likely any other technological option (e.g. an answering
> machine in Alberta that spits out the alphanumerics of the current
> master public key) is still suceptible.
>
> If every piece of information you receive is filter through your
> government, is there any hand-shaking protocol that can allow you to
> establish a verified information connection (not necessarily encrypted)?
> I don't think so.
>
> Sure, Debian has signed .debs that use gpg as a back end (the system is
> called apt-key), it relies on you trusting the fist key that you get
> from them.  Since Debian doesn't actually mail out its own CDs,
> everything is off its mirrors.  apt-key only 'protects' you from a later
> man-in-the-middle.
>
> I think that this is the central 'problem' that people are dancing
> around.
>
> Personally, if this thread is to continue, I would like to see it move
> from a "Why doesn't OpenBSD do things this way?" to a "What are the
> threat models for OpenBSD identity theft and how can we protect
> ourselves?".
>
> Doug.
>
>

--
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
"This officer's men seem to follow him merely out of idle curiosity."
-- Sandhurst officer cadet evaluation.
"Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks
factory where smoking on the job is permitted."  -- Gene Spafford