bluegate010

Some prior art from 2006: https://www.flightglobal.com/darpa-and-nasa-demonstrate-worl...

Video: https://youtu.be/F-Y7fhIasjM

Another talk about LMS / SPHINCS+: https://www.youtube.com/watch?v=lZ1PnJml1CY

Not a stupid question. CDIs are groovy for minting secrets that are bound to the exact firmware that's running, but are a bit less ergonomic out of the box when it comes to keeping long-lived secrets around across a firmware update. Firmware changes --> CDI changes --> anything derived from or sealed to the CDI is gone, by design.

A more ergonomic approach for sealing long-lived data is to use something like a hash chain [0], where the chain starts with the equivalent of a DICE UDS, and the chain's length is (MAX_VERSION - fw.version). The end of that chain is given to firmware, and the firmware can lengthen the chain to derive older firmware's secrets, but cannot shorten it to derive newer firmware's secrets.

This presumes that the firmware is signed of course, since otherwise there'd be no way to securely associate the firmware with a version number. If the public key is not baked into the HSM, then the hash of the public key should be used to permute the root of the hash chain.

[0] https://en.wikipedia.org/wiki/Hash_chain

It sounds like, unless someone is an owner or maintainer of a critical open-source project, the blog post isn't necessarily calling for that person's deanonymization. For projects that are both critical and owned/maintained by anonymous entities, I think it's reasonable for an organization to think twice before taking a dependency on such projects, given the sort of anonymous attacks mentioned in the article.

Disclaimer: opinions are my own, not my employer's (Google)

From the second link:

> It is conceivable that contributors, unlike owners and maintainers, could be anonymous, but only if their code has passed multiple reviews by trusted parties. It is also conceivable that we could have “verified” identities, in which a trusted entity knows the real identity, but for privacy reasons the public does not. This would enable decisions about independence as well as prosecution for illegal behavior.

Many of us on the Asylo team share your reservations about DRM. However, the capability to run software in a not-entirely-trustworthy environment leads to many positive possibilities. For instance, you could imagine a world in which customers didn’t have to trust their cloud vendor or worry about their data falling into unauthorized hands. Or you could implement chat applications which can prove to you that your communications really are being encrypted end-to-end.

In our view, trusted computing has applications well beyond DRM.

Asylo is not tied to EPID; the framework aims to abstract away any unique behavior specific to TEE implementations, and provide a common backend interface that developers can code against. The goal is to allow developers to easily migrate their apps between backends with little to no source-code changes.

Specifically for attestation purposes, Asylo defines the EnclaveAssertionGenerator[1] and EnclaveAssertionVerifier[2] interfaces; these will need technology-specific implementations.

In this initial release we only support a simulated backend, for experimental development. We'll continue looking into specific TEE technologies going forward.

[1] https://github.com/google/asylo/blob/master/asylo/identity/e...

[2] https://github.com/google/asylo/blob/master/asylo/identity/e...

Thanks for the helpful feedback. To answer your question: Asylo is currently x86 specific and provides a simulated enclave backend. We plan on evaluating additional enclave technologies going forward, with the goal of supporting those which gain the most market traction and community support.

Obvious disclaimer: currently working at Google on Asylo.

A couple practical benefits of Titan is that we can use it in many different environments where traditional secure boot is not available. For example, we're using it in both servers and in our custom networking card.

In addition, traditional secure boot doesn't give us a hardware root of trust, nor does it enable tamper-evident logging.

Titan is one of the tools we use to protect against tampering, even down to the bootloader.

If the flash chip holding the boot firmware isn't really a flash chip, then indeed this could present an issue. However, since Titan interposes between flash and the PCH/BMC, it can observe the bytes actually being served.

Titan is just one of several measures we take to harden our stack, and helps us be confident in the software we run. It's a good point though, there are no absolutes in security.

The log signing prevents undetected tampering after-the-fact; the goal is to make it readily apparent when log messages are altered or deleted, even by parties with root access.

Both the Titan chip and all software that runs on it are designed entirely in-house, so we have full control over the stack. And we do have physical tampering countermeasures in place.

With Titan we know exactly how it is designed and how it'll behave. Titan is also platform-agnostic; it can work in many environments that Secure Boot cannot. Secure Boot also doesn't get us nifty features like tamper-evident logging or hardware root-of-trust.

Edit: See [0] where Titan was first briefly introduced earlier this year, for an image of it attached to one of our custom networking cards.

[0] https://www.blog.google/topics/google-cloud/bolstering-secur...

We've actually got Titan earring swag we'll hopefully start distributing at upcoming recruiting / customer events, so images may start cropping up in short order.

Why earrings? See the Titan announce video[0].

[0] https://www.youtube.com/watch?v=kwnWfHq2EfQ&t=1882

Spicy raisin bars, an old family recipe. And a cucumber.

Hey HN, I'm one of the engineers on the team behind Titan, feel free to AMA.

This site exemplifies something that really annoys me with Google's material design framework. On my 13" screen, I can see a grand total of four items at a time: https://i.imgur.com/6YJxj0b.png

I really wish they'd consider information density as a plus when designing pages like this.

Off-topic, but The Guardian's article landing page really needs to be cleaned up: http://i.imgur.com/3LGXU7g.png

I can't make heads or tails of what I'm supposed to pay attention to.

I just recently had weeks of headaches over getting my server's email sent to spam. After setting up a brand new domain, with SPF, DKIM, etc., I woke up one morning to find my domain wasn't resolving.

Eventually I learned it was because Radix, my TLD registry, had noticed my domain on the Spamhaus Domain Blocklist. Who knows why it was added; I definitely hadn't been sending spam. Radix, being proactive, placed a 'serverHold' DNS status on my domain name, preventing it from resolving.

Luckily Spamhaus has an automated form for dealing with false positives. Eventually Radix removed the status. (Though, a week later it was back up, for no reason. Had to badger them for over a week to get the status removed again. Would not recommend them.) It's very lucky I wasn't trying to do anything with that domain like run a business, or rely on @<domainname> addresses to work.

TL;DR the problem is definitely not overstated.

> If your keys are not protected by a passphrase

Looks like the private key can be leaked regardless of the use of a passphrase, but you'd get the encrypted form that would need to be cracked offline.

An issue with passwordless is its vulnerability to passive attack. From perusing the source code, it looks like they authenticate users based on a token and uid embedded in a link sent to the user's email address. If that link is intercepted, an attacker can impersonate the user.

A system that addresses this drawback is SAW [1, 2]; it splits a token in half (via XOR) and sends part of it to the user as a cookie, and part to the user's email address. Clicking the link combines the two and submits them both to the server for validation.

[1] http://isrl.byu.edu/pubs/pp1001.pdf (short) [2] http://isrl.byu.edu/pubs/saw.pdf (long)

We haven't reached out to Mailvelope/Gmail developers, nor have we opened a usability dialogue with the OpenPGP community. We're still in the process of getting these results published. Your experience with that community is interesting though.

For those who value security enough to take the pains to learn the system, yes, it's useful. For your average netizen, we feel a progressive approach would be more effective. Start out with a key escrow service and if the user wants more security, they can ratchet up to PGP.

Interesting; I'd really like to hear what issues you have with that scorecard.

Yes, we probably would have gotten better usability scores if we developed our own PGP client with a better UX and tutorials. We selected Mailvelope because it was rated highly on the EFF's secure messaging scorecard [1] and we were exploring how the state-of-the-art in PGP software actually performed with end users.

[1] https://www.eff.org/secure-messaging-scorecard

That's the exact line of thinking our lab has been on. Security<-->usability is a tradeoff, and PGP seems to sit too far on the secure end of the spectrum to be useful to most users. We're working on a way to deliver progressively enhanced security, while onboarding less technical users with more usable features.

Hey HN, I'm one of the authors on this paper. I'd be happy to answer any questions.