Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
On Tue, Aug 12, 2008 at 9:29 AM, Jerry Vonau [EMAIL PROTECTED] wrote:
Martin Langhoff wrote:
On Tue, Aug 12, 2008 at 2:24 AM, Michael Stone [EMAIL PROTECTED] wrote:
* What use cases are you trying to support?
Insert a usb stick with content that is OK'd by the regional NOC
(network operations centre) for execution/installation on the XS.
-
* What security
properties are you trying to check?
Signed by the NOC, not changed.
Why not encrypt the partition on the usb-stick? Not too sure what all
that would involve, just some food for thought.
Caution, strong encryption is not legal in all the world.
Better to just use signed RPMs and perhaps hand verifiable checksums.
Key point: RPMs can be re-signed.
Some of the most in need parts of the world are places where trust
is most fragile. I suspect that digital signatures and checksums can
be used to keep all the OLPC processes as reliable, open and
transparent as possible. Encryption implies a deep lack of trust to
me. Signed files permits trust and also verification. Also the
ability to extract and verify without a secret the content of any
package might be important in a troubled region.
Summary: RPMs can be re-signed this permits local organizations to
pickup, verify, test and if their policy desires re-sign the packages
for local, regional use.
Fragment from the man page:
Signatures:
rpm {-K | --checksig} [signature-options] PACKAGE_FILE...
rpm {--addsign | --resign} PACKAGE_FILE...
So signed by the NOC, and not changed is possible to do. The
regional NOC may need to manage the secret half of their keys and
distribute the public half of their but that is less of a problem and
more trusting and open than full encryption.
--
T o m M i t c h e l l
mitch-at-niftyegg-dot-com
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
On Thu, Aug 14, 2008 at 7:47 AM, Tom Mitchell [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 9:29 AM, Jerry Vonau [EMAIL PROTECTED] wrote: Why not encrypt the partition on the usb-stick? Not too sure what all that would involve, just some food for thought. Caution, strong encryption is not legal in all the world. Better to just use signed RPMs and perhaps hand verifiable checksums. Also in practical terms, it's fairly hard to create encrypted partitions (on other platforms for example), and RPMs also have high barriers of entry. So I'm looking for something simple, and as portable as possible. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
Martin Langhoff wrote: On Tue, Aug 12, 2008 at 2:24 AM, Michael Stone [EMAIL PROTECTED] wrote: * What use cases are you trying to support? Insert a usb stick with content that is OK'd by the regional NOC (network operations centre) for execution/installation on the XS. * What threats obstruct supporting those use cases? Content could be modified on the way to insert evil sharks with frikking lasers into the XS. * What trust structure are you trying to create and how does it mitigate the threats while permitting the use cases? As I've written, we trust keys put in place at install time. Install time is privileged, root user is privileged. * What algorithms are you going to use and why? Whatever GPG uses for signatures, SHA1 for file integrity because I'd be an idiot to try and be smarter than crypto researchers. * What security properties are you trying to check? Signed by the NOC, not changed. Why not encrypt the partition on the usb-stick? Not too sure what all that would involve, just some food for thought. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
Martin, Thanks for your note. Unfortunately, it left me with more questions than with answers. Some questions include: * What use cases are you trying to support? * What threats obstruct supporting those use cases? * What trust structure are you trying to create and how does it mitigate the threats while permitting the use cases? * What algorithms are you going to use and why? * What security properties are you trying to check? (Perhaps you've already answered some of these basic questions elsewhere and you simply left out the citation?) Two other comments: If you want to go the route of 'signed content lives in directories', then please examine the programs in olpc-contents http://wiki.laptop.org/go/Olpc-contents and let us know in what way they can be improved before writing your own. If you're more interested 'signed content lives in archives', then JAR-signing might be for you! Regards, Michael P.S. - In the future, please consider CC'ing the security@ list when you write security-related mail. Interesting people live there. ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
On Tue, Aug 12, 2008 at 2:24 AM, Michael Stone [EMAIL PROTECTED] wrote: * What use cases are you trying to support? Insert a usb stick with content that is OK'd by the regional NOC (network operations centre) for execution/installation on the XS. * What threats obstruct supporting those use cases? Content could be modified on the way to insert evil sharks with frikking lasers into the XS. * What trust structure are you trying to create and how does it mitigate the threats while permitting the use cases? As I've written, we trust keys put in place at install time. Install time is privileged, root user is privileged. * What algorithms are you going to use and why? Whatever GPG uses for signatures, SHA1 for file integrity because I'd be an idiot to try and be smarter than crypto researchers. * What security properties are you trying to check? Signed by the NOC, not changed. (Perhaps you've already answered some of these basic questions elsewhere and you simply left out the citation?) I could cite ISBN: 978-0-7645-1679-5 :-) I'll look at JAR signing and olpc-contents. Thanks for the pointers... cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
On Tue, Aug 12, 2008 at 2:24 AM, Michael Stone [EMAIL PROTECTED] wrote: If you're more interested 'signed content lives in archives', then JAR-signing might be for you! JARs look good but there don't seem to be decent cli tools to deal with them (can fastjar sign and check sigs in packages?) and big Java deps for the core XS are not in my plans. cheers. m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] A simple signed bundle/directory trust scheme for the XS
On Tue, Aug 12, 2008 at 2:24 AM, Michael Stone [EMAIL PROTECTED] wrote: If you want to go the route of 'signed content lives in directories', then please examine the programs in olpc-contents http://wiki.laptop.org/go/Olpc-contents and let us know in what way they can be improved before writing your own. olpc-contents is fairly close to what I am doing. I am thinking about a few things I want moderately technical people to be able to build and check these bundles (usb based or otherwise) on any modern OS: * What I want from olpc-contents is mostly what sha1sum does, and sha1sum is very portable and widespread - even some GUIs are available. * olpc-contents not being self-contained and not being pure Python hampers things further. IOWs, I cannot say just download this portable python script. Of what olpc-contents adds, I only care about the check for extraneous files. Other bits -- file owners and permissions -- I don't need, and in fact get in the way. I would need a version of olpc-contents that does not include (and later, does not care for) file ownership or mode data. So it's close enough, but it gets in the way in a big time. Just picture the instructions: - Only Windows users: install sha1sum from here - link to exe (sha1sum is in stock OSX and Linuxen) - create an empty dir and put what you want inside - check no stray files are there - run 'sha1sum * manifest.md5' - Windows users, here's an alternative GUI if you want... to - Debian/Fedora users - here's a nice rpm deb - Everyone else: install this python script with its related libraries and bits in C... various pages of explanations based on http://docs.python.org/ext/win-cookbook.html - I quote: To build extensions using these instructions, you need to have a copy of the Python sources of the same version as your installed Python. You will need Microsoft Visual C++ ``Developer Studio''... - create empty dir... Must say - I've read the source and it's a good tool. However my thinking right now is that it doesn't add enough for my use case, and it gets in the way big-time. Just to make it usable for the use cases I have will take several times more work to make it usable than to write the little script I'm thinking of. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] A simple signed bundle/directory trust scheme for the XS
The XS now has a few new packages that allow it to auto-install certain types of content (XO installation builds, for starters) from USB keys. This means that I have to address validating that such content comes from a trusted source. So I am setting up a simple and straightforward authentication scheme for the XS. It does not attempt to solve very possible problem -- physical access to the box and various other issues conspire against us. It humbly attempts to establish a simple yet reasonable chain of trust. Comments welcome. Please do keep in mind that I am trying to keep it simple and implementable in a short timeframe. There following are the main moving parts in this scheme. - Initial installation / boot is trusted. During installation and/or initial boot the XS will read a set of trusted public GPG keys from a USB drive, and copy them somewhere in /etc - more that one set of trusted keys is ok. If this happens, a file will exist in /etc indicating (to scripts and sysadmins) that signature checks are enforced. We may signal this in visible UIs too. - Signed content -- we will consider content as signed correctly if it has at its top directory a file called manifest.sha1 that validates the rest of the files in the directory and a manifest.sha1.sig file containing a GPG signature of manifest.sha1 , signed with one of the trusted keys. To avoid race conditions affecting files in a world-readable directory, the checks should be performed in a safe tmpdir. - Signed content maybe a dir on a usb key, or a directory in a zipfile or a tarball. As long as manifest.sha1 provides a valid manifest for all the files in the corresponding directory and subdirectories. Anything that unpacks to a directory is ok. We will use this scheme for a wide range of things - the files may be retrieved by the XS via the network, or uploaded by users via web interfaces. - Extraneous files - not listed in the manifest - cause an error. - We trust signed content - this includes scripts that will run as root, and can add new pub keys to the trusted set. - If we are not in 'enforcing mode' (XSs in pilots, for example) then we don't check for signatures. - Extraneous files and mismatched SHA1s *always* cause an error. - A utility called xs-check-signature Does the Right Thing (including logging) for scripts when passed the path to the manifest.sha1 file. that's all. More words than implementation code probably - :-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
