Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [serval-project-dev] Re: Unique Opportunity: Input to CEOs of Smartphone Manufacturers

Paul Gardner-Stephen paul at servalproject.org
Mon Jul 15 22:33:13 PDT 2013


Hello all,

Date: Fri, 12 Jul 2013 11:24:27 +0200

> From: Eduardo Robles Elvira <edulix at wadobo.com>
> To: liberationtech <liberationtech at lists.stanford.edu>
> Subject: Re: [liberationtech] Unique Opportunity: Input to CEOs of
> Smartphone Manufacturers
> Reply-To: liberationtech <liberationtech at lists.stanford.edu>
>
> Hello:
>
> I'd like to see a mesh mode in the mobile phones. There are currently
> lots of mesh software initiatives, but I haven't seen any smartphone
> manufacturers support this. In the past, they were dependant of
> telecommunication companies to sell their phones, but now some
> companies are now starting to sell phones by themselves (Google for
> example). A mesh network mode would allow users to communicate even if
> there's no other conection, it can be useful to conect with peers in a
> demonstration or to transmit stream video to them in case police
> breaks your phone.
>

This is basically what we have been working towards with the Serval Project
(servalproject.org, developer.servalproject.org/wiki, igg.me/at/speakfreely),
with built-in end-to-end encryption, and fully distributed operation.

Disaster zones and isolated communities are our primary use cases.
 However, our one trial so far was actually for the kind of use you discuss
above, and showed that people communicated more, and spent less in the
process. It was used to get footage from a protest that ended up online
(see links in the report).  Encryption wasn't baked in at that time, but
now is.  Limited range is being addressed by the Mesh Extender (
igg.me/at/speakfreely). You can read the deployment report here:

http://developer.servalproject.org/dokuwiki/doku.php?id=content:publications:internews2010



> On Fri, Jul 12, 2013 at 1:11 AM, Blibbet <blibbet at gmail.com> wrote:
> >> (1) A unique key built into each device, which can't be read directly
> >> by software, but which can be used to derive other keys (e.g. for disk
> >> encryption) at a limited rate, slowing down brute-force attacks
> >> against such keys.
>

We do this a different way with Serval, by having a master key that is the
private key from which the public network identifier of each node is
derived (the Serval ID or SID).  Network addresses are public keys, which
greatly simplifies a pile of things.

These keys can be, and are used to encrypt arbitrary files that can also be
replicated across the network.  This is actually how text messaging is
implemented on the Serval Mesh.


> >> (2) An effaceable area of flash storage where the operating system can
> >> store encryption keys for the entire disk and/or individual files,
> >> making it possible to securely delete the corresponding data without
> >> having to smash the device into tiny little pieces.


That would be really nice.  Knowing that it isn't likely to happen, our
solution is to never write any sensitive data to flash unless it is
encrypted.  Our keyring format doesn't even store your SID (the public key)
en claire - you must know the unlock PIN(s) to access it.

Provision has been made to erase sensitive identities when unlocking a
specially created disposable identity with a dedicated self-destruct pin.

While it doesn't guarantee erasure of the encrypted keyring block from the
flash, it does make it much harder to recover the deleted identity,
especially if long PINs (really they can be pass phrases) are used.

All this provides the basis for plausible deniability.


>
>
>> (3) A pony.
>

We considered it, but came to the conclusion that it would make the APK
file too large.  Also most modern mobile phones lack a hay chute, and lack
batteries denominated in mOh (milli-oat-hours).

Anyway, we encourage everyone to take a look at what we are doing, pick
holes in it so that we can make it better, and consider helping us to
spread the word for our crowd-funding campaign at igg.me/at/speakfreely

Thanks,

Paul.

> Presuming the smartphone is ARM-based, and presuming if (1) is applied,
> > it'll probably have ARM TrustZone installed, then:
> >
> > (4) Install a modern firmware on your smartphone, with useful security
> > features.
> >
> > (4a) Linux-based Coreboot. or
> >
> > (4b) UEFI.
> >
> > Use UEFI's SecureBoot feature, to enhance your Linux/Android/B2G/etc OS,
> > something none of your competitors are doing, except MS/Win8. To do so,
> you
> > need TPM on x86 or TrustZone on ARM, and you need to get your OS vendor
> to
> > sign the firmware, and not let MS Win8 hardware logo requirements confuse
> > you.
> >
> > Beyond the default TianoCore source, leverage Linaro's ARM-centric fork
> of
> > TianoCore, and Intel's MinnowBoard's UEFI which targets Linux
> > (Angstrom/Yocto), but neither of these Linux-centric UEFI targets support
> > the SecureBoot feature.
> >
> > Extend the current UEFI SecureBoot feature, which only targets 1 OS, to
> one
> > that lets you securely boot more-than-1 OS, for systems that want to
> > securely multiboot a handful of OSes (not necessarily installed, but
> later,
> > if your device is open, your user may opt to install another distro; your
> > job is to gather certs of the major ones, so they can securely boot the
> main
> > distros.)
> >
> > (5) Learn from FairPhone's model. Compete with them, by making something
> > *more* open.
> >
> > Thanks.
> >
> >
> > --
> > Too many emails? Unsubscribe, change to digest, or change password by
> > emailing moderator at companys at stanford.edu or changing your settings at
> > https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
>
> --
> Eduardo Robles Elvira     +34 668 824 393            skype: edulix2
> http://www.wadobo.com    it's not magic, it's wadobo!
> --
> Too many emails? Unsubscribe, change to digest, or change password by
> emailing moderator at companys at stanford.edu or changing your settings at
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130716/e1794997/attachment.html>


More information about the liberationtech mailing list