Hello all, Date: Fri, 12 Jul 2013 11:24:27 +0200
> From: Eduardo Robles Elvira <edu...@wadobo.com> > To: liberationtech <liberationtech@lists.stanford.edu> > Subject: Re: [liberationtech] Unique Opportunity: Input to CEOs of > Smartphone Manufacturers > Reply-To: liberationtech <liberationtech@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 <blib...@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 compa...@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 compa...@stanford.edu or changing your settings at > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
