Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techcrunch.com

Post reply on HN
Print view View original

371–380 of 390 posts

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

#371

Post by baud147258 »

bringtheaction wrote: post #284
oooomm wrote: post #257

Earlier quoted context omitted.

Well every comment thread on the Internet related to the Rift issue mentioned this as a solution so it probably wasn't his idea.

Anyone who had an interest in computers in the mid 90-s to early 2000-s will remember trial software that was good for 30 days but which, if you set the clock back would give you the corresponding amount of extra time. I even seem to recall one that when I set the clock back much more than 30 days gave me as many more days beyond the 30 as as much as I had set it back. Then there were a couple pieces of software that…

I've done it for the games free for a week-end on Steam, when I want to continue playing but I don't want to pay for the game. Of course it only work for single-player games. But changing the date of the computer quickly makes browsing internet unusable, due to certificate check failing.

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

#372

Post by agar »

freeone3000 wrote: post #370
MayeulC wrote: post #306

Earlier quoted context omitted.

Well, I am sorry to have to disagree on this. This is no rocket science, and the software support isn't that different from any standard monitor/gamepad combo. That's for the architecture, at least. Of course, latency requirements are higher. But the differences stops here. Face it, today's VR headsets simply are monitors that you wear on your face (Head Mounted Displays). Anyone thinking otherwise is simply lying to…

The certs are for drivers, not an internet connection. Internet connection is required for updates, for instance, in case you forgot to countersign your drivers against a timeserver. Whoops.

Whoops indeed. :-D

About a $5m whoops, considering Oculus just gave everyone a $15 store credit due to the problem.

Sometimes education is expensive.

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

#373

Post by dockd »

r1ch wrote: post #23

This is not how Windows code signing is supposed to work. Normally you'd get a countersignature from a timestamp server so that the verification process can prove that the certificate was valid at the time of signing. It would appear that Oculus signed their binaries without using a timestamp server, so without a way to verify when signing happened they become invalid as soon as the cert expires.

The Windows signature tool, signtool.exe, makes the timestamp an optional parameter. There are no warnings if you don't supply it. I'd suggest this is a poor design--do most signatures not want the timestamp by default?

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

#374

Post by cheeko1234 »

technofiend wrote: post #86
lopmotr wrote: post #81

Earlier quoted context omitted.

Something like that. Certificates aren't supposed to stop working just because they've expired! That would destroy all abandoned or poorly maintained software within a couple of years. This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.

>Just the fact that the device apparently can't function at all without the internet is a problem too. Isn't Oculus owned by Facebook? Of course it has internet-based mandatory data collection, er uh excuse me, license something something.

FYI, the Oculus does work without internet.

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

#375

Post by braderhart »

dockd wrote: post #373
r1ch wrote: post #23

This is not how Windows code signing is supposed to work. Normally you'd get a countersignature from a timestamp server so that the verification process can prove that the certificate was valid at the time of signing. It would appear that Oculus signed their binaries without using a timestamp server, so without a way to verify when signing happened they become invalid as soon as the cert expires.

The Windows signature tool, signtool.exe, makes the timestamp an optional parameter. There are no warnings if you don't supply it. I'd suggest this is a poor design--do most signatures not want the timestamp by default?

No problems on Linux... problem solved and it is open source and auditable.

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

#376

Post by agar »

MayeulC wrote: post #366
agar wrote: post #315

Earlier quoted context omitted.

Argument: A modern VR stack is much more complex, and does much more, than just displaying images on two screens. Counterargument: The 16 things that happen other than just displaying images on the screen aren't relevant, have been done before, or has equivalent complexity to other systems. Well OK. I just can't argue with that. "A modern CPU SOC is no more than a souped up 6502." That's true, if you ignore the integ…

I would like to apologize for my previous post, I feel that it is unnecessarily long, and a bit inaccurate/exaggerated. Let me be clear: I pretty much agree with everything you said. Only your original statement was what I felt a bit of a stretch: > The "monitor you wear on your face" trope is simply inaccurate, and essentially a misunderstanding of the state of VR today After reading a bit more into it, I feel that…

Thanks, no apologies needed. I didn't mean to come off snarky either. And I obviously am not averse to unnecessarily long messages.

As an aside, Valve's tracking solution is much less USB-intensive than Oculus's.

In Valve's Lighthouse system, sensors on the HMD and controllers use the angle of a laser sweep to calculate their absolute position in a room and provide the dead reckoning needed to correct IMU drift. As a result, the only data being sent over USB is the stream of sensor data and position (I believe sensor fusion still occurs in the SDK, not on device).

Oculus's Constellation system uses IR cameras, synchronized to an IR LED array on the HMD and controllers. The entire 1080p (or 720p, if used over USB2) video images (from 2 through 4 cameras, depending on configuration) are sent via USB to the PC. This is in addition to the IMU data coming from the controllers. The SDK performs image processing to recognize the position of the LEDs in the images, triangulate their position, perform sensor fusion, and produce an absolute position.

The net result is roughly equivalent tracking between the two systems, but the USB and CPU overhead for Rift is greater (it's estimated that 1%-2% of CPU is used for image processing per sensor, but the Oculus SDK appears to have some performance advantages that allow equivalent performance on apps despite this overhead).

There is great debate over which is the more "advanced" solution. Lighthouse is wickedly clever, allowing a performant solution over larger tracking volumes with fewer cables and sensors.

Constellation is pretty brute-force, but requires highly accurate image recognition algorithms that (some say) give Oculus a leg-up in next generation tracking with no external sensors (see the Santa Cruz prototype[1] which is a PC-free device that uses 4 cameras on the HMD and on-board image processing to determine absolute position using only real-world cues). It also opens the door to full-body tracking using similar outside-in sensors.

But overall, the Valve solution definitely lends itself to a Linux implementation better than Oculus's, simply due to the lower I/O requirements. It also helps that Valve has published the Lighthouse calculations (which is just basic math), while Oculus has kept its image recognition algorithms as trade secrets.

[1] https://arstechnica.com/gaming/2017/10/wireless-oculus-vr-gr...

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

#377

Post by Vendan »

dlubarov wrote: post #340
agar wrote: post #304

Earlier quoted context omitted.

Rereading your question, I realize I may have not actually answered an underlying topic: what is the difference between a certificate and a signature? The short answer is: - a "certificate" contains a number of things: a portion of an asymmetric key (either public or private), and a ton of metadata[1] to give information about that key: validity period, algorithms used, version, etc. - a "signature" is the result of…

> So if that creation certificate expires (or is revoked) it calls into question the validity of the signature(s) created from that certificate. Are you arguing that already-installed drivers should no longer be trusted? I can't tell. If a cert expires at time T, the usual assumption is that forging signatures before T is not feasible (otherwise the expiration was poorly chosen), while forging signatures after T migh…

> But if we've already installed a driver, then we must have received its signature before T, otherwise we wouldn't have installed it at the time. So we should still continue to trust it after T.

And now you leave open an attack surface of "forge a signature off an old, expired cert and then fool the OS into thinking it's been installed all along."

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

#378

Post by plussed_reader »

cheeko1234 wrote: post #374
technofiend wrote: post #86

Earlier quoted context omitted.

>Just the fact that the device apparently can't function at all without the internet is a problem too. Isn't Oculus owned by Facebook? Of course it has internet-based mandatory data collection, er uh excuse me, license something something.

FYI, the Oculus does work without internet.

So does Steam, but the metrics filter back to the mothership eventually.

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

#379

Post by dzamo_norton »

barkingcat wrote: post #262
mattnewport wrote: post #181

Our VR surgical training startup has been working for the last few months towards a big medical conference this week where we're showing multiple training procedures for multiple customers on Oculus Rift, as well as having our own booth. The headsets all stopped working the morning of the conference. Fortunately one of our engineers figured out we could get our demo rigs working by setting the clock back a few days.…

This does not bode well for real VR surgery. Imagine if this were surgery day for someone, and because of an expiring certificate the rift shuts down ...

Then you fall back to normal surgery.

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

#380

Post by gmueckl »

zaarn wrote: post #353
gmueckl wrote: post #263

Earlier quoted context omitted.

What is a legitimate use case for a binary deliverable without a timestamped signature?

As you might have guessed, when you don't want someone to use a binary beyond a certain date. Security Solutions could benefit from this, the customer will have to update or disable the signature check if their version of the solution becomes too old. Old versions could open them up to vulnerabilities. Another might be when you distribute beta or testing versions of your software. The customers can safely test the ve…

The customer can always re-sign the binary if they wante to and replace the existing signature. A time limited inside the program code would be more secure.
Post reply on HN