Live data from Hacker News

All of Oculus’s Rift headsets have stopped working due to an expired certificate

techcrunch.com

41–50 of 390 posts

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#41
Something similar just happened to me. I have a windows computer I only Use for gaming. After the last update My Samsung display is no longer usable. It has a polarized effect now only when using the windows Computer. However the Computer Works fine Connected to another brand monitor. So much money, yet windows still sucks when it comes to most basic things

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#43

They let their certificate expire, essentially bricking all of their devices. And now the app running it won't start, so they can't push an update. Just recently picked up a Rift. I love the hardware and their exclusives are top notch, but this confirms my suspicions that their backend is super goofy. They sell Rifts at Best Buy and want to pretend that it's a consumer-ready product, but here's why I am recommending…

I see the exclusives as a negative. I don't want to support their efforts to build a closed ecosystem around what should be an open API that any headmounted display + tracking can expose.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#45

Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1] https://search.thawte.com/support/ssl-digital-certificates/i...

What happens when the countersigning service's cert expires?

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#46
post #30

Earlier quoted context omitted.

The problem isn't that Windows requires drivers to be signed. The problem is that Windows allows drivers to have an expiration date. If Windows verifies a driver's signature at the time the driver is installed, the driver should be considered trustworthy for as long as it remains installed on that system. There's no reason to re-verify the signature every time the driver is used .

Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.

That seems silly. Presumably a cert has an expiration date after which we might assume its been compromised. If it has been compromised then it could have been used to backdate a driver signed with it. In other words, if you don't trust the cert you should not trust anything signed by it. Or is there another layer in this somewhere?

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#47
post #44

In 2091, an overworked developer will accidentally let the certificate expire for the Planetary Shield Defense Matrix, and the Zylorts will finally conquer Earth.

Sounds like the work of a double agent...

Hanlon's Razor? https://en.wikipedia.org/wiki/Hanlon%27s_razor

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#48
One wonders if we've made technology unnecessarily complicated. In order to build something like the Oculus Rift, they obviously needed expertise in hardware design, optics, display technology, manufacturing, user interface design, etc etc. Also, they apparently needed expertise in managing the ins-and-outs of the Windows driver security system. Adding one more subject to their already crowded curriculum wasn't very nice of Microsoft.

A lot of applications and environments seem to be built with the assumption that they can add arbitrary complexity to their interface, since they're only going to be used by "experts" who can be expected to know everything of relevance and work through a thick documentation to understand the system. In truth, the "experts" who use your programs are going to also be using a dozen other applications, each with their own piles of documentation (or equal amounts of lack-of-documentation,) and have little brain-space left for the intricacies of your framework. So, they're going to use your system while knowing the minimum possible amount about it; if that system contains traps that cause problems for this kind of user, that's bad design.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#49
post #45

Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1] https://search.thawte.com/support/ssl-digital-certificates/i...

What happens when the countersigning service's cert expires?

By adding a timestamp to digital signatures, trust conditions are changed to the following list:

* data is not tampered

* signing certificate was time valid at signing time: signing time is within signing cert's validity

* Neither certificate was revoked before signature generation

* both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store).

https://serverfault.com/a/878950

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#50

Earlier quoted context omitted.

Recommended practice is to timestamp windows drivers (and software) when they are signed. Without a timestamp, the driver is not trusted after the signing cert expires, which I guess is what happened here. With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.

That seems silly. Presumably a cert has an expiration date after which we might assume its been compromised. If it has been compromised then it could have been used to backdate a driver signed with it. In other words, if you don't trust the cert you should not trust anything signed by it. Or is there another layer in this somewhere?

The timestamp server is a separate trusted entity that signs the signature asserting the date and time. It's not just metadata, it's effectively a separate signature.
Post reply on HN