
Google’s Project Vault Is a Computing Environment on a Micro SD Card - harshabhat86
http://techcrunch.com/2015/05/29/googles-project-vault-is-a-secure-computing-environment-on-a-micro-sd-card-for-any-platform/
======
kfreds
This makes me very excited but also a bit sad. I'm developing a similar
product, so this is great validation. On the other hand, this is quite the
competition.

Could someone share a link to the original presentation? I'd love more
technical details.

Is this SDHC or SDXC compatible? If they support SDXC, how do they reconcile
"fully open source" with the fact that SDXC requires exFAT which is
proprietary and protected by patents?

Building something like this requires an SD Slave Controller. It would be
absolutely fantastic if they open source that! Fully verified and SDXC
compatible? This makes me drool. Unfortunately the necessary information to
implement and verify is walled behind NDAs (SD Association), unless of course
you have reversed it with a logic analyzer. I don't think that's what Google
has done, which makes me very curious.

If the slave controller is not open source, that begs the question of how data
is transferred to the RTOS. A closed source core with DMA to whatever you run
on it will exclude it from certain privacy-sensitive use cases.

If anyone at Google is reading this, consider using cores from cryptech.is for
your crypto. You're already a funder so you might as well reuse them.

If anyone is interested in what I just said and you think you can contribute I
would love to talk with you. Email me at stromberg@mullvad.net.

~~~
dm2
I've seen that happen before with a startup, they actually shutdown just
because Google launched a superior product first.

Then less than 1 year later Google cancelled that project and now there is
nobody to provide that service.

~~~
electrograv
_> Then less than 1 year later Google cancelled that project and now there is
nobody to provide that service._

This made me imagine some poor, bright but new-hire Google PR employee
realizing this popular (and quite correct) view of Google ("CANCEL ALL THE
THINGS" [1][2]) frantically trying to figure out how to actually communicate
to upper management (without getting fired) the blunt truth:

This ongoing strategy of announcing projects and promptly canceling them after
a few years is incredibly damaging to the company. Google's "ADHD-like low
attention span" to projects is anything but confidence-inspiring. :(

1\. [http://memegenerator.net/X-All-The-
Things](http://memegenerator.net/X-All-The-Things)

2\. HN likes numbered references and I do too

~~~
JesperRavn
No one would get fired for saying that, but (clearly) the company has decided
that the current strategy is the right one.

My take is that Google is less developer-friendly than Microsoft and Apple.
Google does not rely on external developers as much, because so much revenue
comes from web based, directly consumer facing products. Google is always
trying new things, because they are looking for the next big user facing
product. This might annoy developers who build against Google's APIs, but that
is worth it because Google relies on users, not loyal developers. It is a
fundamentally different approach from Windows or iOS.

~~~
foxylad
Doesn't MS rely on users too? Users of Windows, instead of users of browsers,
but it's still in both of their interests to get developers using their
platforms.

At the end of the day, _all_ large companies have to dip their toes in new
technologies, or die. Some of these projects will work out and others won't.
Small companies do the exact same thing, except instead of announcing they are
discontinuing a project they go bust.

My approach is not to get too tied to any vendor's technology, because if you
do, you're setting yourself up for a fall. The rise of open source and
standards has made this much easier than it once was, luckily.

~~~
devsquid
Yea, exactly. But fan boyism runs deep in this industry, particularly on
forums. It incredible to see my collogues get so caught up in one mega corp
and then spend so much of their time trashing 'their' mega corps competition.
I use each for what they are worth and I enjoy to watch them come, go, and
compete.

~~~
JesperRavn
I don't work for Microsoft, and it's sad that you assume anyone with a
different opinion from yourself is a fanboy.

~~~
devsquid
I said "But fan boyism runs deep in this industry, particularly on forums. It
incredible to see my collogues get so caught up in one mega corp and then
spend so much of their time trashing 'their' mega corps competition." Where am
I generally calling people with different opinions than mine fan boys. I agree
and disagree with many fan boys. I am a fan of the products I use, but I am
quick to move to new products if I have the means and my experience with the
other products is superior.

------
forgottenpass
_Google’s ATAP said the micro SD format made sense because there’s already
advanced security features on your phone, contained in the SIM card, which
protects the things important to carriers. Vault is designed to be an
equivalent, but designed to project a user’s important content._

How exactly does this help on a mobile platform that is architected to enable
easy and legal exfiltration of user data?

It seems like a difficult sell to imply I can't trust the smartphone's primary
storage for key material, but to trust processes on the same system with the
plain text.

I know why this is useful in the abstract (I use a yubikey as an openpgp card
to keep key material off my computer and phone) but the class of attacks it is
designed for are not the attacks smart phone users face daily and en mass.
(I'd trade in the yubikey in an instant for a platform with a stronger
permission system, and apps that don't send home a copy of all data I allow
them to operate on.)

~~~
x0x0
why aren't you using an iphone then? Apple's business model is not the
systematic sale of your information to advertisers.

They're _far_ from perfect, but look at eg app permission systems. Android's
next gen os finally catches up to what ios has had for quite a while. It's
pretty clear where priorities lie.

~~~
forgottenpass
Because I can use more than one criteria when making a purchase decision?

I've had iphones too. When I did, I was able to care about users other than
myself, and how the status quo effects us all.

The difference in first party surveillance is real, but they both court
developers to their platforms with little regard for how much surveillance
they will or will not do. The problems are the same there, and the minor
differences are merely dressing around the edges. They're just hyped to be
bigger than they are because people love a rivalry and websites love clicks.

~~~
x0x0
well yes, this is the real world and you have to make tradeoffs; privacy
apparently isn't important enough to you

the differences are more than window dressing; one company is an advertising
company and the other isn't. One company's messaging platform is only
encrypted in transit to the company; the other's is architected so they can't
read your messages.

Again, I'm not claiming apple is perfect on privacy, but they are better than
google.

------
PinguTS
_Onboard the Vault itself is an ARM processor running ARTOS, a secure
operating system focused on privacy and data security._

Am I the only one wondering why there is no information available about that
OS? Google is in many ways committed to Open Source and then it is using a
proprietary OS where I do not find any information about.

There is a Wikipedia comparison table with an outdated link. There is an old
entry on a blog with basically zero information, except there where only a
single person involved in designing and developing this OS. Which makes it
suspicious to me regarding the claim "safe and secure".

~~~
TazeTSchnitzel
I think "ARTOS" is a mishearing of "a RTOS".

~~~
gillianseed
The only potentially relevant 'ARTOS' I found was here:

[http://en.wikipedia.org/wiki/Comparison_of_real-
time_operati...](http://en.wikipedia.org/wiki/Comparison_of_real-
time_operating_systems)

Which lists an active X86 project and a defunct ARM project named ARTOS, both
proprietary.

------
kfreds
Here's a link to the original presentation:
[https://youtu.be/mpbWQbkl8_g?t=2851](https://youtu.be/mpbWQbkl8_g?t=2851)

Remember L0pht and cDc? This is a project lead by Peiter Zatko aka Mudge. His
Wikipedia page is a piece of hacker history.

Also see
[https://twitter.com/dotMudge/status/604295695751749633](https://twitter.com/dotMudge/status/604295695751749633)

------
mariusz79
Isn't it ironic that Google's own Nexus phones won't be able to use this as
they don't have microSD card connector?

~~~
Vexs
I never thought of that! Hopefully if vault becomes a common thing, we'll see
more phones with microSD card slots! To be honest, a large part of choosing my
phone was if it had a card slot or not, they give so many extra capabilities.

~~~
sliverstorm
It's mostly the Nexus line that doesn't have SD cards. Google was/is a big
believer that multiple storage devices makes for bad user interaction.

------
bravo22
Such a thing, more or less, exists today. It is called Secure Element[1]. It
comes in microSD + NFC or embedded as part of SmartCard/SIM card. Incidentally
this "secure element" is why GooglePay was/is dependant on carriers. The
carriers already have a secure element (in their SIM) to authenticate you on
their network.

It seems the real value in what they've done is expand the software support
for it by, hopefully, making it a key part of Android API.

[1]
[https://www.datacard.com/downloads/ViewDownLoad.dyn?elementI...](https://www.datacard.com/downloads/ViewDownLoad.dyn?elementId=repositories/downloads/xml/NFC-
micro-sd-secure-elements-data-sheet.xml&index=1&repositoryName=downloads)

~~~
sangnoir
That's explicitly called out in the article:

> ...there’s already advanced security features on your phone, contained in
> the SIM card, which protects the things important to carriers. Vault is
> designed to be an equivalent, but designed to project a user’s important
> content.

SIM card is controlled by carrier, and protects carriers' cryptographic
interests. The vault is independent of the Secure Element: it user-controlled,
and protects user's cryptographic interests.

~~~
bravo22
Correct. The carrier controls that SE, in this case Google is making it easier
for people to work with their own SE by giving Android ability to talk to it.

You can/could do the same thing with carrier's SIM actually. All SEs run
something called Java Card, which is a standard API you can write against (in
Java). Each app gets it's own isolated part of the secure storage, and runs in
complete sandbox from other apps and can communicate to apps on the host
device.

The chip inside the SIM and the SDCard are pretty much the same. Just
different packaging.

------
seccess
"Vault is designed to be an equivalent, but designed to project a user’s
important content."

Gotta love a typo that, hilariously, says the opposite of what is meant.

~~~
kelvin0
It's valled double speak (see 1984)

~~~
peeters
I'm not sure I see the parallels to 1984 here. This seems more like a Freudian
Slip [1].

1\.
[http://en.wikipedia.org/wiki/Freudian_slip](http://en.wikipedia.org/wiki/Freudian_slip)

------
pimlottc
ATAP = Google's Advanced Technology and Projects group, for those who are not
familiar with it.

~~~
SEJeff
Perhaps GARPA is a better name?

~~~
serf
"Produced by GARPA under funding by DARPA" at the end of every video may be
kind of entertaining to hear narrated.

------
ilurk
How does this brings additional security?

If Alice types a message in her phone and the phone is compromised -- such as
the telecom owning the baseband processor which can access all of the device
memory -- how does it guarantee that the text entered is not captured by the
telecom?

~~~
ENGNR
It means they can't steal the key, so the attacker has to actually have root
on the device whenever new data is sent. That's risky for the attacker as they
could be found out and possibly have their entry vector / zero day patched
worldwide.

It also has open source random number generators, another defence against a
passive attacker and requiring them to have root on the device.

------
drazvan
How is this different from let's say Swissbit (
[http://www.swissbit.com/index.php?option=com_content&view=ar...](http://www.swissbit.com/index.php?option=com_content&view=article&id=291&Itemid=599)
) or DeviceFidelity ([http://www.credense.com/](http://www.credense.com/)) or
GoTrust ( [http://www.go-trust.com/](http://www.go-trust.com/) ) or any
generic ASSD card (
[https://www.sdcard.org/developers/overview/ASSD/](https://www.sdcard.org/developers/overview/ASSD/)
)? Those are all programmable using JavaCard and contain secure tamper-
resistant chips.

~~~
kfreds
None of those products are, to my knowledge, open source.

Vault might very well implement the ASSD specification. However, to use ASSD
the OS needs to be able to send ASSD-specific low-level SD commands to the
card. It would require patching the OS, and depending on the phone it might
not work anyway.

Assuming Google sticks to the open source promise that will drive developer
adoption. Using the standard memory interface and normal file system
operations to do crypto makes it potentially compatible with just about
anything. It's also easy to interface with. Everything is a file! :)

------
sargun
This is super interesting for embedding into servers as an HSM-like device. A
lot of servers have SDIO ports internally. Any idea what the cost is going to
be?

~~~
kfreds
If you're looking for an open source HSM take a look at cryptech.is

------
higherpurpose
It seems it was discussed at the I/O session here:

[https://youtu.be/26Bma3d0wko?t=10m39s](https://youtu.be/26Bma3d0wko?t=10m39s)

Vault actually starts at 17:50.

EDIT: Hmm. There seems to be some problem with Google's videos. When another
"live session" that's supposed to be added at the same video link begins, you
can't watch the previously recorded video anymore.

------
polonia
You can see all the code in

[https://github.com/projectvault/orp](https://github.com/projectvault/orp)

You can see the demo at
[https://www.youtube.com/watch?v=mpbWQbkl8_g](https://www.youtube.com/watch?v=mpbWQbkl8_g)

Cheers, Pedro

------
nickpsecurity
Google so far hasn't shown much knowledge of endpoint security, uses many
stacks with huge attack surface, and plays penetrate/patch. That's from their
web services all the way to mobile. Third parties, both companies and FOSS
types, are doing better at protecting Android than Google. Although there's
exceptions, Google seems mostly unqualified or uncaring in terms of strong
INFOSEC.

So, I have little trust in the security of ARTOS or Vault for now. I tried to
review the ARTOS kernel's design but they pulled it off their site. So, we
have nothing to go on but their word. I can't wait to get some more objective
information about its design and implementation for a real review.

~~~
kllrnohj
> Google so far hasn't shown much knowledge of endpoint security, uses many
> stacks with huge attack surface, and plays penetrate/patch.

[citation needed]

> Third parties, both companies and FOSS types, are doing better at protecting
> Android than Google.

such as...?

> Although there's exceptions, Google seems mostly unqualified or uncaring in
> terms of strong INFOSEC.

Eh? What's your basis for this claim? They are pretty much always on the
latest & greatest. ECHDE_RSA, certificate pinning, universal 2nd factor
(FIDO), strong sandboxing & permissions (you may not remember, but those were
things Google took mainstream with Chrome & Android). Google's also the
company that took security vulnerability rewards and made that a thing.

Plenty of things to dislike Google about (privacy is always an easy target,
for example), but security really isn't one of them. They have one of the best
trackrecords you can have here.

~~~
dmix
> Third parties, both companies and FOSS types, are doing better at protecting
> Android than Google.

I'm working on a 3rd-party OSS project securing Android
[https://copperhead.co/android](https://copperhead.co/android) (/shameless
self plug)

While Android is in pretty bad shape, I'd still give Google some credit, they
have been slowly starting to improve their OS security in the last 2 years.
But quite a few early design choices favouring performance over security, such
as Zygote rendering ASLR ineffective, are lingering and holding back Android's
security.

They are also using Linux kernels from 2012 or earlier (3.4) on almost all
devices, although from what I've heard that is mostly the fault of vendors
such as Qualcomm moving slowly.

~~~
nickpsecurity
Good for you. We Android users appreciate people picking up Google's slack. :)
It looks like your people are mixing the regular hardening advice with some
ported stuff from BSD/Linux security work. This is low-medium in that it won't
stop serious attackers if you get popular. Yet, even baking in the basic
hardening by default should reduce risk of many real-world attacks. The other
stuff might do more in final form. Keep at it.

~~~
dmix
Having read a few of your other comments I'd be curious to hear your thoughts
on ways in which we could harden Android (on here or via email).

Our focus now is indeed adding memory protections to the underlying OS, to get
Android up to date with at least 2004-era exploit mitigation. Before moving on
to higher-level stuff :)

~~~
nickpsecurity
Linux is so inherently insecure that it's hard to say without processor &
toolchain modifications. What you can do is follow lead of the others: combine
a microkernel (eg OKL4, OC.L4) with paravirtualized Android with security-
critical components running outside of Android. The Nizza Architecture [1]
below illustrates this. A better, but commercial, approach [2] shows how to
handle drivers and some other things better. It's been deployed in a
ridiculous number of phones with success. So, standardize on a phone,
audit/test the crap out of the drivers, put an OKL4/Nizza-style architecture
on it, and pull out anything security-critical to run on microkernel with
_careful_ input validation & state management. Should reduce TCB, increase
reliability, and prevent spoofing if you fully implement Nitpicker for mobile.
Hope that helps.

Quick note: be sure to clear all internal registers and cache if kernel
transitions from trusted software to untrusted software if you're worried
about covert channels (esp key leaking). Both of those can leak keys to
professionals if they compromised the Android portion.

[1] [http://os.inf.tu-dresden.de/papers_ps/nizza.pdf](http://os.inf.tu-
dresden.de/papers_ps/nizza.pdf)

[2]
[http://www.eit.lth.se/fileadmin/eit/project/142/virtApproach...](http://www.eit.lth.se/fileadmin/eit/project/142/virtApproaches.pdf)

------
chenzhekl
Where can it be used? On the contrary, I'm really worried about my privacy.
Creating a backdoor in the firmware can be easier and more hidden.

------
atap
I guess I'm just _supposed_ to know what ATAP means.

------
frik
Reminds me of the Western Europe chip cards with Sun MicroJava runnung in it.

