Google’s Project Vault Is a Computing Environment on a Micro SD Card(techcrunch.com)
techcrunch.com
Google’s Project Vault Is a Computing Environment on a Micro SD Card
http://techcrunch.com/2015/05/29/googles-project-vault-is-a-secure-computing-environment-on-a-micro-sd-card-for-any-platform/
19 comments
Don't take this as a bad sign, just because Google is behind it doesn't mean they're devoting a lot of resources to it or that they'll hit the right mark.
Build your vision and be better than your competitors.
Build your vision and be better than your competitors.
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.
Then less than 1 year later Google cancelled that project and now there is nobody to provide that service.
> 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
2. HN likes numbered references and I do too
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
2. HN likes numbered references and I do too
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.
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.
I disagree, Google constantly gives developers free resources and run a very powerful and cheap cloud network. I think they are at least on par with Microsoft. I am a developer and I don't use any ms products, but I use quite a few of the ones Google offers. Google's cloud is significantly cheaper than Azure as well (actually GCN is about on par with most others, its just Azure is very expensive), I have compared many times. About Apple, I love their products, but they aren't very developer friendly. Their eco system is very closed, they don't support many tools other than the ones used to developer directly to their platform. Their eco system is just very profitable, so we put up with it. I have always seen it as, Google is the developer's company, Microsoft's the enterprise company, and Apple's the consumer's company.
A few examples
>AngularJS
>AOSP
>Google Maps
>GCN
>Chrome Dev Tools
>Polymer and Material Design
>Go
>Dart
A few examples
>AngularJS
>AOSP
>Google Maps
>GCN
>Chrome Dev Tools
>Polymer and Material Design
>Go
>Dart
I observed the same thing. Microsoft is the company who cares about developers more.
I can tell my odd experience about Microsoft: my company reverse engineered many of its products and offered APIs around products without APIs. One day someone from QA sent us an e-mail offering help if some of these products have issues with Windows 7!
I can tell my odd experience about Microsoft: my company reverse engineered many of its products and offered APIs around products without APIs. One day someone from QA sent us an e-mail offering help if some of these products have issues with Windows 7!
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.
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.
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.
I don't work for Microsoft, and it's sad that you assume anyone with a different opinion from yourself is a fanboy.
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.
Google search, GMail, Youtube are not platforms. They don't rely on an ecosystem of external developers. Android is, but it is generally considered less developer friendly than iOS.
Any reference on it being "generally considered less developer friendly"?
I get the impression that MS these days are trying to depreciate Windows in favor of their cloud services.
In a sense it is a return to the MS that was before the IBM PC, when they were supplying office and development tools to all comers (MS Office got its start on Apple computers after all).
In a sense it is a return to the MS that was before the IBM PC, when they were supplying office and development tools to all comers (MS Office got its start on Apple computers after all).
For a long time Google Drive for the desktop didn't exist and a company name InSyncHQ built a desktop client. I thought for sure that spelled doom for them. Nope, they've been chugging along ever since. In fact GDrive has ceased to innovate so heavily that I've personally switched back to Dropbox. Don't let Google's involvement deter you...Google fails a lot and is not immune to the innovators dilemma. Chances are you'll find something they miss and you'll win.
To this day, Insync is still infinitely better than the real client.
> Could someone share a link to the original presentation?
The presentation is here: https://www.youtube.com/watch?v=mpbWQbkl8_g&t=47m23s (starts around 47:23).
The presentation is here: https://www.youtube.com/watch?v=mpbWQbkl8_g&t=47m23s (starts around 47:23).
> quite the competition.
Understatement of the century. However, I see it as great news for you. If you're far along enough, and this proves to be something people want, you're a shoo-in for a buyout. Good luck and keep up updated.
Understatement of the century. However, I see it as great news for you. If you're far along enough, and this proves to be something people want, you're a shoo-in for a buyout. Good luck and keep up updated.
But – as shocking as this might be for some people here – a buyout might be not what people strive for. Some people just want to have their own small company, thinking more long term. Others want to actually improve the world.
Eh. I mean yeah there are companies designed from the ground up to be bought out in just a couple years, yes, but there isn't anything wrong with doing great work and getting bought out by people improving the world too, right? It seems like in that case you're both trying to "improve the world" and you're teaming up.
In a recent episode of Silicon Valley, the billionaire president of a company said to his employees "I don't want to live in a world where someone else makes the world a better place, better than we do."
In a recent episode of Silicon Valley, the billionaire president of a company said to his employees "I don't want to live in a world where someone else makes the world a better place, better than we do."
Aiming for a buyout doesn't mean you don't also want to improve the world.
Your tone is pretty offensive. It would shock almost no one on this site that someone would like to build their own business without an aim to sell it or that someone would have philanthropic life-goals in general.
Many business owners who are bought out turn to philanthropic pursuits now that they've become fiscally stable.
Your tone is pretty offensive. It would shock almost no one on this site that someone would like to build their own business without an aim to sell it or that someone would have philanthropic life-goals in general.
Many business owners who are bought out turn to philanthropic pursuits now that they've become fiscally stable.
My tone is aggressive because someone was working on a project, a larger company picks up the same idea, and the first suggestion is to give up completely, and accept to be bought out.
Instead of considering any of the other options, or that the small company could actually compete with the larger company (hint: Google doesn’t operate most of their services outside of the US at all), the only real suggestion is "you’re in for a buy-out".
Instead of considering any of the other options, or that the small company could actually compete with the larger company (hint: Google doesn’t operate most of their services outside of the US at all), the only real suggestion is "you’re in for a buy-out".
GP doesn't want to improve the world via philanthropic pursuits - they want to improve it by offering an alternative via something they've built. With that in mind, it seems that the suggestion that a buyout by the competition would be a better way to improve the world via (non-thought-out) philanthropy is itself a somewhat offensive suggestion.
This is true, but when one if that competition is too great, it might be a viable exit strategy to consider (rather than just closing up shop).
Here's the RTL BTW: https://github.com/ProjectVault/orp/tree/master/hardware/mse...
The testbenches in that directory are supposedly too basic to have been used for development (a few directed test cases per module). I wonder why they wouldn't release the proper testbenches?
Eh, a lot of industry doesn't write as many test benches as they should. I've worked for companies that have written no test benches.
I had a similar thing happen when I found out one of my competition got funding from Mark Cuban and the another competitor got a pretty big round (fresh from their graduation at YC).
But then I thought about it. What a wonderful validation of our idea. And we think we can do it better.
Look at the angles and if you have to reshape your idea then do so. Maybe some competitive advantage you have will stick out or you'll develop it after seeing their offering. But think of this as a good thing. Investors love competition. It means there's a market.
But then I thought about it. What a wonderful validation of our idea. And we think we can do it better.
Look at the angles and if you have to reshape your idea then do so. Maybe some competitive advantage you have will stick out or you'll develop it after seeing their offering. But think of this as a good thing. Investors love competition. It means there's a market.
I would not worry one bit. I have successfully competed against multi-billion dollar companies. If you have a better product and are good at marketing there's nothing they can do to stop you. Small startups can move like Neo, while large companies can't get out of their own way.
Google doesn't make products, but tech demos.
Keep on going, the world needs more of people like you.
Keep on going, the world needs more of people like you.
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.)
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.)
> but to trust processes on the same system with the plain text
I don't know if that is necessary from what the details are showing.
It looks like there are two dummy files that act are used to stream data between the two OSes meaning the phone does not necessarily have unlimited access.
I don't know if that is necessary from what the details are showing.
It looks like there are two dummy files that act are used to stream data between the two OSes meaning the phone does not necessarily have unlimited access.
But surely whatever data the phone is piping to and from those dummy files can be read while it's still plaintext?
The distinction is that random access to the files need not be provided.
If I give your phone access to /usr/private_key.txt then the OS has total control. If I instead give you a way to sign messages then the OS has much weaker ability to control (obviously some amount if the device is connected and capable of signing).
If I give your phone access to /usr/private_key.txt then the OS has total control. If I instead give you a way to sign messages then the OS has much weaker ability to control (obviously some amount if the device is connected and capable of signing).
Wasn't one big key Argument immutable logging. So you have at least a good chance to know, if you where compromised and maybe even get to know how they did it.
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.
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.
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.
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.
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.
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.
replying to self -- over here [1] people are discussing apple shutting down an app that uses url handlers to scrape the other installed apps on an ios device. The crucial difference: android just lets you query this.
[1] https://news.ycombinator.com/item?id=9625916
While Android has an API for fetching a user's installed applications, Apple
did not include one, and even removed the ability to access a device's
UDID--steps clearly made with the intention of preventing the profiling of
users and the leaking of personal information.
[1] https://news.ycombinator.com/item?id=9625916
As android user , if you cared about app permissions, all you needed to do was to install cyanogenmod.
all you need to do is root your phone, install a new os, and deal with all the downstream issues?
That's just not at all what I want for my phone. Right now, it basically more or less works, and I really like that. I simply don't want to turn it into yet another thing I have to administer, follow security updates for, and deal with when it breaks.
And even if I can do it for myself, the majority of users can't and/or won't.
That's just not at all what I want for my phone. Right now, it basically more or less works, and I really like that. I simply don't want to turn it into yet another thing I have to administer, follow security updates for, and deal with when it breaks.
And even if I can do it for myself, the majority of users can't and/or won't.
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".
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".
Looks like they have some code on Github:
https://github.com/ProjectVault/orp/tree/master/software/os/...
OK, that looks like the right way. But there is still a thing: the article reads ARM and this code is for openRISC 1200. Also this uses an OS called: mselOS
Something is wrong.
https://github.com/ProjectVault/orp/blob/master/mainpage.dox
Something is wrong.
https://github.com/ProjectVault/orp/blob/master/mainpage.dox
The dev board in the picture gallery says that it's an openRISC softcore.
Maybe they've migrated to an ARM in the real formfactor?
EDIT: Here are the ARM drivers in the OS. https://github.com/ProjectVault/orp/tree/master/software/os/... It's a CortexM.
Maybe they've migrated to an ARM in the real formfactor?
EDIT: Here are the ARM drivers in the OS. https://github.com/ProjectVault/orp/tree/master/software/os/... It's a CortexM.
I'm 99% certain they meant Free RTOS[0] and someone just misheard.
[0]http://en.wikipedia.org/wiki/FreeRTOS
[0]http://en.wikipedia.org/wiki/FreeRTOS
I don't think FreeRTOS has an emphasis on security and privacy. It's strengths are portability, small footprint, and open source.
I think "ARTOS" is a mishearing of "a RTOS".
The only potentially relevant 'ARTOS' I found was here:
http://en.wikipedia.org/wiki/Comparison_of_real-time_operati...
Which lists an active X86 project and a defunct ARM project named ARTOS, both proprietary.
http://en.wikipedia.org/wiki/Comparison_of_real-time_operati...
Which lists an active X86 project and a defunct ARM project named ARTOS, both proprietary.
That's very possible. It could be any RTOS with a good security track-record in industry, from OKL4 to INTEGRITY-178B. There's also a number of groups doing R&D on Assured Real-Time OS's so it could be that. That we still don't know and RTOS security is so hard bothers me about this.
[deleted](1)
In PinguTS's link, I found this document with a description on the RTOS:
https://github.com/ProjectVault/orp/blob/master/software/os/...
I'll review it later on. Anyone else want to chime in about its security at this point?
https://github.com/ProjectVault/orp/blob/master/software/os/...
I'll review it later on. Anyone else want to chime in about its security at this point?
[deleted]
Here's a link to the original presentation: 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
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
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?
> 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?
Not particularly. It would be moreso if that were true of Nexus-branded phones released after Vault was generally available.
Not particularly. It would be moreso if that were true of Nexus-branded phones released after Vault was generally available.
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.
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.
SD cards are not popular in the US. Googler's also thought they were no longer popular. Mudge pointed out that outside of the US (emerging markets, Europe, etc) they are an essential feature.
Nexus phones also didn't even have a secure element before, unlike the high end choices from Samsung, etc. (which had non-standard support). Pretty annoying.
What makes you think so? My Nexus S and Nexus 4 both have secure elements.
OK, I meant the ones currently being sold: Nexus 5, etc.
The next gen do.
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...
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...
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.
> ...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.
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.
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.
[deleted]
AFAIK the secure element for Google Wallet is part of the NFC chip.
Almost. The biggest hurdle in SE is "provisioning", i.e. how do you get your master keys in there. This is why Google needed to rely on the carriers for authentication. They already have a full infrastructure for that in place.
The NFC chip in Nexus for example (PN5323 IIRC) interfaces with an external secure element[1], which would be in the SIM card in their case and in the new use cases it would be the external uSD card. The NFC chip passes data transparently between the external NFC device and the SE like a bridge.[2]
I believe in Apple's case they just built an SE directly into their chip and came up with their own provisioning infrastructure, bypassing the carrier. Which I think is the better way. That is what Google should have done.
[1] http://www.adafruit.com/datasheets/pn532ds.pdf (page 20) [2] http://en.wikipedia.org/wiki/NFC-WI
The NFC chip in Nexus for example (PN5323 IIRC) interfaces with an external secure element[1], which would be in the SIM card in their case and in the new use cases it would be the external uSD card. The NFC chip passes data transparently between the external NFC device and the SE like a bridge.[2]
I believe in Apple's case they just built an SE directly into their chip and came up with their own provisioning infrastructure, bypassing the carrier. Which I think is the better way. That is what Google should have done.
[1] http://www.adafruit.com/datasheets/pn532ds.pdf (page 20) [2] http://en.wikipedia.org/wiki/NFC-WI
"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.
Gotta love a typo that, hilariously, says the opposite of what is meant.
It's valled double speak (see 1984)
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
1. http://en.wikipedia.org/wiki/Freudian_slip
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?
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?
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.
It also has open source random number generators, another defence against a passive attacker and requiring them to have root on the device.
How is this different from let's say Swissbit ( http://www.swissbit.com/index.php?option=com_content&view=ar... ) or DeviceFidelity (http://www.credense.com/) or GoTrust ( http://www.go-trust.com/ ) or any generic ASSD card ( https://www.sdcard.org/developers/overview/ASSD/ )? Those are all programmable using JavaCard and contain secure tamper-resistant chips.
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! :)
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! :)
It seems it was discussed at the I/O session here:
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.
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.
You can see all the code in
https://github.com/projectvault/orp
You can see the demo at https://www.youtube.com/watch?v=mpbWQbkl8_g
Cheers, Pedro
https://github.com/projectvault/orp
You can see the demo at https://www.youtube.com/watch?v=mpbWQbkl8_g
Cheers, Pedro
[deleted]
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.
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.
> 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.
[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.
> 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 (/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.
I'm working on a 3rd-party OSS project securing 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.
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.
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 :)
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 :)
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
[2] http://www.eit.lth.se/fileadmin/eit/project/142/virtApproach...
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
[2] http://www.eit.lth.se/fileadmin/eit/project/142/virtApproach...
Bad shape? How so?
Zygote is more about memory than performance, and that's still a needed thing. SELinux is in enforcing mode and has an increasingly tighter and tighter net.
Also Google is using 3.10 on the devices they sell, not 3.4. What Samsung, HTC, etc... ship is a different story, but that's not under Google's control.
Zygote is more about memory than performance, and that's still a needed thing. SELinux is in enforcing mode and has an increasingly tighter and tighter net.
Also Google is using 3.10 on the devices they sell, not 3.4. What Samsung, HTC, etc... ship is a different story, but that's not under Google's control.
> Zygote is more about memory than performance
Memory = performance. We disabled Zygote and performance took a hit (ie, apps start slower because classes aren't preloaded).
> Google is using 3.10 on the devices they sell, not 3.4.
3.10 is on some new devices such as Nexus 9, including Lollipop upgrades for Samsung S6 and HTC M9.
Google Nexus 5/7 is 3.4.
So basically <=3.4 is on 99.99% of Android devices...
Memory = performance. We disabled Zygote and performance took a hit (ie, apps start slower because classes aren't preloaded).
> Google is using 3.10 on the devices they sell, not 3.4.
3.10 is on some new devices such as Nexus 9, including Lollipop upgrades for Samsung S6 and HTC M9.
Google Nexus 5/7 is 3.4.
So basically <=3.4 is on 99.99% of Android devices...
First part: name one high assurance system Google has ever produced or a low assurance system that top tier hackers gave up on? Did their mobile OS have a strong TCB with POLA on the apps and trusted path? Did their web services use native code (minimal attack surface) with checks manually or automatically built in to stop most attacks? Did they perform a covert channel analysis on their cryptographic stuff? Do they know what those are unlike many INFOSEC types I meet? Has anything they designed used an architecture that made leaks or code injection nearly impossible? If not, then my statement stands until Google demonstrates the ability to make a secure product or one that approximates that. They haven't caught up to Daniel Bernsteins' Qmail claims much less top-tier work like KeyKOS [1] or Burroughs [2]. Ancient, top tier work...
Re third parties. There are numerous academic teams doing hardware or compiler work on making Linux-based systems immune to code injection or at least isolated. OK Labs did OKL4 with user-mode Android for isolation. Samsung leveraged INTERGITY microvisor in Knox. Perseus Security Framework did something similar with a Linux personality, modified by Sirrix or SYSGO I believe for mobile. Control-pointer integrity does this on hardware supporting segments (x86). DIFT catches when incoming data screws with pointers and such, also ported to Linux. Automated diversification and keyed hardware SOC's to make Linux probabilistically secure. Several methods ported to Linux to stops leaks or injection with crypto tricks. Many things Google could've used for mobile and non-mobile. NSA did SEAndroid. Then there's Tor, modders, and Android developers tools/tips to lock down Android and turn off Google's leaks. About everyone but Google did great work in securing Android.
To test you on your own claims, would you trust a vanilla Android installation's security out of the box or make some modifications first? I'd mod it or assume I'm game for whoever.
re unqualified in strong INFOSEC
Everything you mention they, like IT in general, built on foundations of quicksand: low assurance hardware, firmware, and software that has regularly been defeated by skilled hackers. So, sure they pushed some good security technologies that stop low to mid-grade hackers or solve pieces of the puzzle (see my use of "exceptions"). Yet, Google themselves and their Android users were hacked with quite vanilla techniques due to their system and software architecture. There are systems in EAL6/7 and under SPOCK program that NSA pentesters couldn't breach despite having 2+ years to try. Matasano said something similar about Secure64's SourceT OS, too. The things they have in common is bottom-up, end-to-end, medium-to-highly assured (EAL6+) lifecycle. That's strong requirements, design, implementation, analysis, testing, build, configuration, and independent verification of that. Google hasn't done (censored) in this area despite having the brains to do so. Matter of fact, their smartest work IIRC was Native Client and it was smashed because they intentionally weakened the security model for performance reasons.
Almost all their stuff has been knocked down by serious hackers or subversions. It's why they needed the bug bounty. Smart idea if you're pushing low to mid grade throughout your whole stack. Didn't stop the Chinese and NSA from smashing them. They didn't even need esoteric techniques. The definition of high assurance security is the level of rigorous security engineering needed to resist well-funded, sophisticated threats with time on their hands. They never came close, so why do you trust them to do it now without proof? Trust, but verify.
[1] http://www.cis.upenn.edu/~KeyKOS/
[2] http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
Re third parties. There are numerous academic teams doing hardware or compiler work on making Linux-based systems immune to code injection or at least isolated. OK Labs did OKL4 with user-mode Android for isolation. Samsung leveraged INTERGITY microvisor in Knox. Perseus Security Framework did something similar with a Linux personality, modified by Sirrix or SYSGO I believe for mobile. Control-pointer integrity does this on hardware supporting segments (x86). DIFT catches when incoming data screws with pointers and such, also ported to Linux. Automated diversification and keyed hardware SOC's to make Linux probabilistically secure. Several methods ported to Linux to stops leaks or injection with crypto tricks. Many things Google could've used for mobile and non-mobile. NSA did SEAndroid. Then there's Tor, modders, and Android developers tools/tips to lock down Android and turn off Google's leaks. About everyone but Google did great work in securing Android.
To test you on your own claims, would you trust a vanilla Android installation's security out of the box or make some modifications first? I'd mod it or assume I'm game for whoever.
re unqualified in strong INFOSEC
Everything you mention they, like IT in general, built on foundations of quicksand: low assurance hardware, firmware, and software that has regularly been defeated by skilled hackers. So, sure they pushed some good security technologies that stop low to mid-grade hackers or solve pieces of the puzzle (see my use of "exceptions"). Yet, Google themselves and their Android users were hacked with quite vanilla techniques due to their system and software architecture. There are systems in EAL6/7 and under SPOCK program that NSA pentesters couldn't breach despite having 2+ years to try. Matasano said something similar about Secure64's SourceT OS, too. The things they have in common is bottom-up, end-to-end, medium-to-highly assured (EAL6+) lifecycle. That's strong requirements, design, implementation, analysis, testing, build, configuration, and independent verification of that. Google hasn't done (censored) in this area despite having the brains to do so. Matter of fact, their smartest work IIRC was Native Client and it was smashed because they intentionally weakened the security model for performance reasons.
Almost all their stuff has been knocked down by serious hackers or subversions. It's why they needed the bug bounty. Smart idea if you're pushing low to mid grade throughout your whole stack. Didn't stop the Chinese and NSA from smashing them. They didn't even need esoteric techniques. The definition of high assurance security is the level of rigorous security engineering needed to resist well-funded, sophisticated threats with time on their hands. They never came close, so why do you trust them to do it now without proof? Trust, but verify.
[1] http://www.cis.upenn.edu/~KeyKOS/
[2] http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
Care to show the huge attack surface in ChromeOS for example?
I'd have to have its full details in front of me. Given how netbooks usually work, I'll hit you with a few questions and review it further if you have secure answers. Does it use regular firmware for its hardware or firmware hardened against attack? Are the drivers isolated in user-mode? Is the trusted software verified by eye, tool, or both to avoid all known code injections? Was that verified by third parties? Does it avoid software with huge TCB and many vulnerabilities such as Linux? Does it avoid Web apps and tech such as Flash?
If yes to all of these, then it's a start on strong security and definitely worth reviewing if only to help close remaining holes. Otherwise, it's probably already received a number of patches and not worth a review. Which is it?
If yes to all of these, then it's a start on strong security and definitely worth reviewing if only to help close remaining holes. Otherwise, it's probably already received a number of patches and not worth a review. Which is it?
From a political standpoint I don't know how many people would trust a Google product with security. Just the brand does not jive with the idea of security. Perhaps the product is good, I don't know. But FUD is in order considering the brand and its general past actions.
I agree. The Snowden leaks showing they're tight with NSA can't help that, either. I'll go further, though, with my main privacy argument against companies such as Google: the incentives of an ad-driven company are 100% opposite of privacy-seeking users. Expecting Facebook, Google, Yahoo, etc to protect one's privacy is ludicrous as they get more money for each privacy violation if not convicted in court.
The only kind of company that can be even semi-trusted is one that where you are the paying customer and their contract + host country's laws protect your privacy/security. Even more so if they have to contractually or legally pay huge fines for negligence. Align the incentives, then there's potential. If opposite incentives, turn 180 degrees and start running.
The only kind of company that can be even semi-trusted is one that where you are the paying customer and their contract + host country's laws protect your privacy/security. Even more so if they have to contractually or legally pay huge fines for negligence. Align the incentives, then there's potential. If opposite incentives, turn 180 degrees and start running.
[deleted]
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.
[deleted]
I guess I'm just supposed to know what ATAP means.
Reminds me of the Western Europe chip cards with Sun MicroJava runnung in it.
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 [email protected].