[Cryptography] Open Source Sandboxes to Enforce Security on Proprietary Code?

Maarten Billemont lhunath at lyndir.com
Tue Aug 19 13:45:01 EDT 2014


On Aug 15, 2014, at 9:42 AM, Kent Borg <kentborg at borg.org> wrote:
> Designing in end-to-end encryption is a good idea, but just because there is a claim that some product employs end-to-end encryption, why should any customer believe it?
> 
> With open source programs there is a go-check-for-yourself response that, though it might not be practical, does pose a risk of discovery to those who might want to try to quietly inject a backdoor.
> 
> But that doesn't do any good in assuring that a proprietary product is in anyway secure.
> 
> Is there any work going on to build an open/closed hybrid, where a the closed source portion of the code is in a restricted sandbox that can't talk to the outside world, except through limited facilities provided by the open source portion, a part that is susceptible to go-check-for-yourself auditing?
> 
> One doesn't have to worry as much about what product Foo is doing if we encrypt all its communication with a key that Foo doesn't know. Sure, Foo might implement a covert channel, but if we don't let it talk to untrusted endpoints, so what? Don't think of it as a covert channel, think of it as a proprietary feature that makes Foo's voice quality better than the competition's.
> 
> Individual products might release portions of their source code to try to demonstrate how wholesome they are, but some standardization would be better.
> 
> Recent Linux kernels have seccomp filters that can restrict and filter system calls, and that sounds useful, but is rather incomplete. The open source portions of Android made an attempt at implementing permission lists on app sandboxes, but it is full of holes.
> 
> Are their other Usual Suspects are in this space?
> 
> -kb, the Kent who has been musing over a product idea and but who is wondering how it could possibly be considered trustworthy.
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography


Along with the claim of using open source code needs to come the ability to verify that the shipped product is not a modified version of said code and/or a way to replace the open source part of the proprietary system with a self-compiled and debuggable version of the open source code, both technically and legally.

Not to open a can of worms, but this is exactly the reason behind the distinction between free software and non-free open source software.

— Maarten Billemont (lhunath) —
me: http://www.lhunath.com – business: http://www.lyndir.comhttp://masterpasswordapp.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140819/3a463c85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140819/3a463c85/attachment.bin>


More information about the cryptography mailing list