[Cryptography] POLA, was Re: letsencrypt.org

Bill Frantz frantz at pwpconsult.com
Tue Sep 19 17:37:12 EDT 2017


On 9/19/17 at 5:02 AM, cryptography at lakedaemon.net (Jason 
Cooper) wrote:

>This is why I chose acme-client [1] (not the PHP acme-client, nor the
>ruby acme-client, but the C one from BSD).  It is deliberately designed
>from day one to protect the private keys.  Even in the event of
>compromise via the connections to the acme servers.  From their website:
>
>You don't want the private key processes interacting with anybody else
>(acctproc.c, keyproc.c). You don't want network-touching processes
>interacting with the file-system (dnsproc.c and netproc.c). You don't
>want the process parsing (revokeproc.c) your certificate — which comes
>down the pipe and might be rigged to blow — to touch your file-system or
>the network. Same goes with the process converting the downloaded
>certificates to the format usable by your web server (certproc.c).
>Moreover, you don't want the process scribbling in your webroot to
>scribble elsewhere (chngproc.c). Same goes with the process scribbling
>in your public certificate directory (fileproc.c).
>I'm not advocating for one client over the other.  But I am saying that
>individuals deploying clients, especially with automated updating, need
>to set minimum criteria for security.  Then disregard clients that don't
>meet that.  Personally, acme-client works for me, but ymmv.
>
>thx,
>
>Jason.
>
>[1] https://kristaps.bsd.lv/acme-client/
>_

This kind of structuring is a necessary practice for any program 
where security is important. (It can also help with 
reliability.) It is called the Principle of Least Authority 
(POLA) and protects the system when an attacker finds a bug in 
one of the components. It requires an environment which enforces 
access controls with a high degree of assurance that they can 
not be bypassed.

Programs with this kind of structuring have bee implemented in 
Linux-like systems (e.g. Postfix), and at the language level 
using Javascript, Java, and other memory-safe languages.

If Bluetooth stacks had been written using this kind of 
structuring, the BlueBorne attacks would have been a lot less effective[1].

I would say that anyone who says, "Oh, I don't need to use POLA. 
I can write perfect code." is a fool. I would also point them to 
the first exploit in the referenced paper. It is a classic 
buffer overrun written by a Linux kernel programmer, who should 
know better, and not caught by the code review process.

Cheers - Bill

[1]<http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf> 
describes the Bluetooth protocol and the BlueBorne set of 
exploits. It notes that the spec for Bluetooth is 2822 pages.

------------------------------------------------------------------------
Bill Frantz        |"Insofar as the propositions of mathematics 
refer to
408-356-8506       | reality, they are not certain; and insofar 
they are
www.pwpconsult.com | certain, they do not refer to reality.” 
-- Einstein



More information about the cryptography mailing list