They intentionally wired it so the key memory output only goes into the key input of a crypto engine - it can't be read back without decapping the CPU and microprobing it, and they may have put in countermeasures against that.
The key is a derivative of the PIN that has been encrypted by a device-unique AES key that can be set and erased but NOT read back. The only thing that is wired to that memory cell's outputs is an AES engine's "key" input.
So it's not quite a PUF but it's pretty close.
Best route of attack other than decapping the chip and microprobing it is likely DPA.
Forgot about this, but CRI might have some tricks up their sleeve. They MIGHT have the ability to DPA the AES engine if Apple didn't license their countermeasures - http://www.rambus.com/security...
Apple devices have an additional "trick" beyond just PBKDF2 - There's a random AES key burned into the CPU, and it's wired such that it can be set/erased, but not directly read - it can only be fed as the key into an AES engine.
I am not sure if Apple's PBKDF2 has this AES engine as part of the loop, or if it just feeds the key that comes out of PBKDF2 through the AES engine, but the end result is, on any given device, the AES key that results from a given passphrase is unique to that device and cannot be reproduced off-device.
So if someone just clones the device's flash contents, they have to resort to brute-forcing AES directly, as opposed to trying to brute-force passcodes.
So you can only brute-force passcodes on-device (something like 80ms per try on this model, newer models have a 5 seconds per try limitation), and Apple's software doesn't even allow you to do that. The FBI wants to at LEAST get on-device brute-force capability.
Which might still take years if the user had a reasonably strong passphrase.
Most modern SoCs have the ability to verify u-boot prior to execution. Either the public key, or a hash of it (The little documentation I could find on TI's architecture was that to avoid storing 2048 bits in efuses, they stored a 128-bit hash of the 2048-bit key in efuses. The chip would verify the key (while in flash, could not be changed due to fixed hash), then use that key to verify uboot. TI had extensions to uboot to support hardware accelerated verification of the next stage in the boot chain.
Note: My bit counts might be off. Might be 1024/256, 4096/256, or ???
In nearly every SoC currently available now, the chain is: IROM (or similar) bootloader baked into the SoC. This verifies the signature of uboot, and jumps to it for execution Uboot then takes over, verifies the next step in the chain (if configured to do so), then jumps to it if it verifies.
Note: The IROM signature checks prevent you from replacing uboot with something that does not enforce signature verification.
I know the guy. Justin Case is NOT his real name. (I don't know what it is, I remember seeing him acknowledged by his real name once but I forget what it is, but I do know that it's not his real name - but many people think it is.)
Apache does not require release of source AND does not have the advertising clause of the "older" BSD licenses, so I'm not sure what about this project might be violating the Apache license. Overall Apache is pretty permissive and it's hard to violate except by providing source code but claiming said source code as your own (e.g. removing copyright notices and replacing them) - strangely, releasing a binary-only Apache component with no advertising (e.g. every Android device on the market except for Nexus devices) is more legal than releasing source for the component that removes all original author credit. I do recall the Android-x86 guys were pretty unhappy about RemixOS being effectively a for-profit kang, but the nature of Apache was such that there wasn't much they actually could do about it.
GPL is a whole other story. If they are failing to provide sources in compliance with the GPL then they can burn. (Technically they have to provide sources themselves, but I will let someone slide who says "We used unmodified upstream sources which can be found at X" when there is no evidence to the contrary.)
Yeah, as much as I like Android, it is not suitable for desktop systems except for a few special niches.
I can see it making sense for someone to do an HTPC build that was Android-based in order to run Android games. But to be honest a SHIELD Android TV would be an easier/better/likely cheaper solution for Android games, especially since many of them only have ARM native components and have a severe performance hit on x86.
It makes no sense as a desktop/educational OS right now - which is why the Pixel C has been slammed by so many for having an OS inappropriate to the type of product.
They advertise that. It costs $95/month and you get what you pay for.
(According to others, you CAN enable "binge on" with that plan, and you get "extra" stuff for doing so. Kind of like how Amazon gives Prime users movie rental credits if they choose "slowboat" shipping instead of the free 2-day)
It's pretty clearly specified that if you enable Binge On with your account, your data gets throttled.
The only hole seems to be that there are certain cases where having Binge On enabled results in a throttle but not "free" data from the sounds of it.
I have zero problems with this since you, as a user, CAN TURN IT OFF. (TFA indicates that the issue is users who have Binge On enabled causes throttling in cases of providers not part of Binge On.)
That said, if you already have a functional Android app, ARC is probably easier. Works great for Quasseldroid if you remove one socket configuration call (TCP_KEEPALIVE socket option) currently not supported by ARC.
That's probably part of it. The Netflix Connect box eliminates much of an ISP's backhaul costs.
In T-Mobile's case, their backhaul costs are probably not nearly as much as their spectrum/tower costs. (Although I know in the early LTE transition days, tower backhaul WAS an issue, but I think Netflix's solution was more of a provider core network thing...) So perhaps I should treat "backhaul from Internet to core network" as different from "backhaul from core network to tower". This system helps them manage the backhaul from the core network to towers and then on to the phone, as that's where most of their costs lie.
The things that have triggered many of the big NN debates have been providers throttling their connectivity to the rest of the world - "core-to-Internet" backhaul. Many of these providers have more than enough core-to-customer bandwidth.
In some ways, the way I read it is that T-Mo will effectively spend money (in terms of engineering resources/staffing) in working with a content provider to come up with a proper solution.
It sounds a lot like how some people have described our wired Internet infrastructure in large hubs works - frequently engineers from multiple providers would work together to come up with the optimal solution, sometimes with one provider loaning equipment to the provider connecting to them. At least - that's the way it worked until Verizon or Comcast started pulling their shenanigans. (There was a really good writeup 1-2 years ago shaming one of the providers that was trying to extort Netflix by intentionally not upgrading any link to one of Netflix's backbone providers, which would also punish anyone ELSE on the same provider. Verizon said it was too expensive, the backbone provider replied along the lines of, "bullshit, it requires $20k of equipment we're happy to provide ourselves that we have sitting on a shelf 10 feet away from where it needs to be, we just need permission to install it."
The "kickbacks" could be in the forms of "technical support".
While the theory posted in the article (that automatic rate adjustment) indicates that this should be OK with any content provider, the truth is, rate detection of some providers (think cbs.com in 2014 for example, and SlingTV at all times) is REALLY horrible.
Let's face it - you're going to get much better rate detection (for example, not even bothering to try a 720p stream) if you can explicitly tell the content server - this connection will NEVER go above X mbps.
One use case they could be specifically trying to avoid is: Server automatically attempts 720p. User gets stuttery/buffering video for a few seconds before the ratelimiter detects the actual bandwidth of the connection and drops down. Some ratelimiters (just like TCP's congestion control) may be very aggressive and might drop to 360p before going to 480p after some period of reliable 360p video. If the carrier (I'm guessing they're implementing a proxy in this case based on how they're describing it...) explicitly states they have a ratelimit of X mbps, the streaming server can automatically choose a quality setting just under this limit, rather than spending 10-20 seconds or more trying to determine what it is.
Yup. I've always been surprised at how a proprietary and closed standard (Z-Wave) provided superior interoperability to an open one (ZigBee Lighting Link).
ZLL interoperability is rare. I purchased the Hue specifically because it had the capability to add "other" ZLL lights such as Cree's bulbs. I also 100% ditched Greenwave's crap because it had zero interoperability with anything and they broke the ability for any other HA system to command their gateway.
I tried a few "Connected by TCP" lights (actually made by Greenwave IIRC) and had them working well with my Vera.
A firmware update for the controller rendered them unusable with anything but Greenwave's own app.
So I bought a few Cree smartbulbs to replace them and use with my Hue system - they have been working great for over a year.
Now Philips is going to block these perfectly-functioning lights? FU Philips. The only reason I use your products is that they integrated well into my home system. If you force me to use your products separately from the rest of my home control systems - you'll force me to ditch your products.
Sensor wire that effectively acts as a fuel cell powered by glucose is embedded under the skin for 7 days. (measures interstitial fluid glucose concentration instead of measuring blood directly). On top of the sensor wire is a small clip that a transmitter clips into. This periodically samples data and transmits it with a very low-power RF transmitter (TI proprietary protocol) every 5 minutes. 6 months battery life for the transmitter.
The new G5 system uses BLE, which takes battery down to 3 months despite being physically larger.:(
Getting a sensor to last past 7 days is possible, but it becomes a game of chance. Past 7, risk of infection/scarring/biofouling increases. Longest I've ever worn a sensor was 13 days and honestly I'm not doing that again (that site is healing more slowly than I'd like...)
CGM's such as Dexcom's G4 are pretty close to this. The main disadvantage is you need to insert the sensor under your skin once every 7 days... But then fingersticks are only needed for calibration purposes after that.
Well technically you're not supposed to make treatment decisions without a confirmation fingerstick, but... Most diabetics including myself will go for the carbs if there's any possibility the CGM is correct when it says 55.
As a diabetic, I'm actually not too impressed. Remember needleless injectors? Yeah, they do exist and are still in use in cases where people want to give mass vaccinations in an assembly-line fashion, but they're actually much more painful than needles. This patent sounds a LOT like a needleless injector. All of that mechanical complexity is going to make it significantly larger (and hence less convenient) than a traditional lancing device.
Its benefit is minimal since fingersticks are on their way to being relegated to being a calibration source for CGM systems. I believe Dexcom's goal is to reduce from 2 calibrations per day to 1 with the G6. Admittedly, I still usually do 3-5 fingersticks a day, but I used to do 5-8, more if I suspected my bloodsugar was being wacky.
From one diabetic to another - under the assumption you're Type I - the Dexcom G4 was a life-changer for me. I would absolutely recommend it to any Type I diabetic. Being able to see my bloodsugar simply by looking at my watch (xDrip + NightWatch + Moto 360) is amazing.
Honestly, the complexity and description of this really reminds me of those needleless injectors. They're kind of notorious for bruising and actually being more painful than a fine needle - which is why no one with diabetes (including myself) use them. There's no way anything involving air pressure and vacuum barrels is going to be smaller than most lancing devices. It could be useful for mass high-volume testing in hospitals or something... But even with the removal of needles there are so many contamination concerns still.
Also, in general, fingersticks for diabetics will eventually be relegated to being a calibration reference for CGM systems like Dexcom's G4/G5 (I believe Google Life Sciences is partnered with Dexcom now...) Technically you're not supposed to use a CGM to make treatment decisions without a fingerstick, that said - many diabetics (including myself) do make treatment decisions based on their Dexcom. You can make this system as convenient and painless as possible, it's not going to replace an automatic reading every 5 minutes.
There were two reasons I bought a PS3 back in the day: 1) Final Fantasy XIII -- OOOOPS. Epic fail there. 2) Sony seemed to be doing a good job of atoning for their past mistakes with DRM and rootkits... The PS3 did run Linux for a while after all, and even after the OtherOS fiasco, they were overall doing better. The PS3 was a fairly open or at least "standards-based" system - standard USB peripherals, mostly standard Bluetooth profiles. Overall, I think that under Kaz Hirai, Sony has for the most part been moving far away from their old shenanigans of old. (Of interest: Sony's previous CEO rose up through their media/film divisions. Hirai rose up through the consumer electronics/computer entertainment division.)
I was quite happy with my PS3, which is why I went for the PS4 and I have no regrets. That said - if everyone I knew gamed on Xbox One and I played more multiplayer games than just Destiny, I would consider an Xbox. (I basically played no multiplayer games prior to Destiny, and have overall been lucky to find enough friends that play it on either console to find people on the same console I own.)
Slashdot Mirror
Pretty much par for the course for Cyngn these days.
Also - gotta love how they decided to create a deliberately confusing name in order to steal search results for CyanogenMod.
They intentionally wired it so the key memory output only goes into the key input of a crypto engine - it can't be read back without decapping the CPU and microprobing it, and they may have put in countermeasures against that.
A lab operating on an image will have to directly brute-force AES, as the PBKDF2 result is encrypted with a device-specific key before it is used.
e.g. entering pin 0000 will result in a different AES key on every individual device in existence.
The key is a derivative of the PIN that has been encrypted by a device-unique AES key that can be set and erased but NOT read back. The only thing that is wired to that memory cell's outputs is an AES engine's "key" input.
So it's not quite a PUF but it's pretty close.
Best route of attack other than decapping the chip and microprobing it is likely DPA.
Forgot about this, but CRI might have some tricks up their sleeve. They MIGHT have the ability to DPA the AES engine if Apple didn't license their countermeasures - http://www.rambus.com/security...
Apple devices have an additional "trick" beyond just PBKDF2 - There's a random AES key burned into the CPU, and it's wired such that it can be set/erased, but not directly read - it can only be fed as the key into an AES engine.
I am not sure if Apple's PBKDF2 has this AES engine as part of the loop, or if it just feeds the key that comes out of PBKDF2 through the AES engine, but the end result is, on any given device, the AES key that results from a given passphrase is unique to that device and cannot be reproduced off-device.
So if someone just clones the device's flash contents, they have to resort to brute-forcing AES directly, as opposed to trying to brute-force passcodes.
So you can only brute-force passcodes on-device (something like 80ms per try on this model, newer models have a 5 seconds per try limitation), and Apple's software doesn't even allow you to do that. The FBI wants to at LEAST get on-device brute-force capability.
Which might still take years if the user had a reasonably strong passphrase.
Most modern SoCs have the ability to verify u-boot prior to execution. Either the public key, or a hash of it (The little documentation I could find on TI's architecture was that to avoid storing 2048 bits in efuses, they stored a 128-bit hash of the 2048-bit key in efuses. The chip would verify the key (while in flash, could not be changed due to fixed hash), then use that key to verify uboot. TI had extensions to uboot to support hardware accelerated verification of the next stage in the boot chain.
Note: My bit counts might be off. Might be 1024/256, 4096/256, or ???
In nearly every SoC currently available now, the chain is:
IROM (or similar) bootloader baked into the SoC. This verifies the signature of uboot, and jumps to it for execution
Uboot then takes over, verifies the next step in the chain (if configured to do so), then jumps to it if it verifies.
Note: The IROM signature checks prevent you from replacing uboot with something that does not enforce signature verification.
I know the guy. Justin Case is NOT his real name. (I don't know what it is, I remember seeing him acknowledged by his real name once but I forget what it is, but I do know that it's not his real name - but many people think it is.)
Apache does not require release of source AND does not have the advertising clause of the "older" BSD licenses, so I'm not sure what about this project might be violating the Apache license. Overall Apache is pretty permissive and it's hard to violate except by providing source code but claiming said source code as your own (e.g. removing copyright notices and replacing them) - strangely, releasing a binary-only Apache component with no advertising (e.g. every Android device on the market except for Nexus devices) is more legal than releasing source for the component that removes all original author credit. I do recall the Android-x86 guys were pretty unhappy about RemixOS being effectively a for-profit kang, but the nature of Apache was such that there wasn't much they actually could do about it.
GPL is a whole other story. If they are failing to provide sources in compliance with the GPL then they can burn. (Technically they have to provide sources themselves, but I will let someone slide who says "We used unmodified upstream sources which can be found at X" when there is no evidence to the contrary.)
Yeah, as much as I like Android, it is not suitable for desktop systems except for a few special niches.
I can see it making sense for someone to do an HTPC build that was Android-based in order to run Android games. But to be honest a SHIELD Android TV would be an easier/better/likely cheaper solution for Android games, especially since many of them only have ARM native components and have a severe performance hit on x86.
It makes no sense as a desktop/educational OS right now - which is why the Pixel C has been slammed by so many for having an OS inappropriate to the type of product.
They advertise that. It costs $95/month and you get what you pay for.
(According to others, you CAN enable "binge on" with that plan, and you get "extra" stuff for doing so. Kind of like how Amazon gives Prime users movie rental credits if they choose "slowboat" shipping instead of the free 2-day)
It's pretty clearly specified that if you enable Binge On with your account, your data gets throttled.
The only hole seems to be that there are certain cases where having Binge On enabled results in a throttle but not "free" data from the sounds of it.
I have zero problems with this since you, as a user, CAN TURN IT OFF. (TFA indicates that the issue is users who have Binge On enabled causes throttling in cases of providers not part of Binge On.)
"Writing VLC in JavaScript and other Web technologies, as Chrome OS requires, is not an easy task by any stretch."
No... ChromeOS has ways to write native and semi-native apps:
NaCL - https://developer.chrome.com/n... and PNaCL
That said, if you already have a functional Android app, ARC is probably easier. Works great for Quasseldroid if you remove one socket configuration call (TCP_KEEPALIVE socket option) currently not supported by ARC.
That's probably part of it. The Netflix Connect box eliminates much of an ISP's backhaul costs.
In T-Mobile's case, their backhaul costs are probably not nearly as much as their spectrum/tower costs. (Although I know in the early LTE transition days, tower backhaul WAS an issue, but I think Netflix's solution was more of a provider core network thing...) So perhaps I should treat "backhaul from Internet to core network" as different from "backhaul from core network to tower". This system helps them manage the backhaul from the core network to towers and then on to the phone, as that's where most of their costs lie.
The things that have triggered many of the big NN debates have been providers throttling their connectivity to the rest of the world - "core-to-Internet" backhaul. Many of these providers have more than enough core-to-customer bandwidth.
That doesn't seem to be the case for Binge On, since T-Mo states their criterial in a public document:
http://www.t-mobile.com/conten...
In some ways, the way I read it is that T-Mo will effectively spend money (in terms of engineering resources/staffing) in working with a content provider to come up with a proper solution.
It sounds a lot like how some people have described our wired Internet infrastructure in large hubs works - frequently engineers from multiple providers would work together to come up with the optimal solution, sometimes with one provider loaning equipment to the provider connecting to them. At least - that's the way it worked until Verizon or Comcast started pulling their shenanigans. (There was a really good writeup 1-2 years ago shaming one of the providers that was trying to extort Netflix by intentionally not upgrading any link to one of Netflix's backbone providers, which would also punish anyone ELSE on the same provider. Verizon said it was too expensive, the backbone provider replied along the lines of, "bullshit, it requires $20k of equipment we're happy to provide ourselves that we have sitting on a shelf 10 feet away from where it needs to be, we just need permission to install it."
The "kickbacks" could be in the forms of "technical support".
While the theory posted in the article (that automatic rate adjustment) indicates that this should be OK with any content provider, the truth is, rate detection of some providers (think cbs.com in 2014 for example, and SlingTV at all times) is REALLY horrible.
Let's face it - you're going to get much better rate detection (for example, not even bothering to try a 720p stream) if you can explicitly tell the content server - this connection will NEVER go above X mbps.
One use case they could be specifically trying to avoid is: Server automatically attempts 720p. User gets stuttery/buffering video for a few seconds before the ratelimiter detects the actual bandwidth of the connection and drops down. Some ratelimiters (just like TCP's congestion control) may be very aggressive and might drop to 360p before going to 480p after some period of reliable 360p video. If the carrier (I'm guessing they're implementing a proxy in this case based on how they're describing it...) explicitly states they have a ratelimit of X mbps, the streaming server can automatically choose a quality setting just under this limit, rather than spending 10-20 seconds or more trying to determine what it is.
Yup. I've always been surprised at how a proprietary and closed standard (Z-Wave) provided superior interoperability to an open one (ZigBee Lighting Link).
ZLL interoperability is rare. I purchased the Hue specifically because it had the capability to add "other" ZLL lights such as Cree's bulbs. I also 100% ditched Greenwave's crap because it had zero interoperability with anything and they broke the ability for any other HA system to command their gateway.
I tried a few "Connected by TCP" lights (actually made by Greenwave IIRC) and had them working well with my Vera.
A firmware update for the controller rendered them unusable with anything but Greenwave's own app.
So I bought a few Cree smartbulbs to replace them and use with my Hue system - they have been working great for over a year.
Now Philips is going to block these perfectly-functioning lights? FU Philips. The only reason I use your products is that they integrated well into my home system. If you force me to use your products separately from the rest of my home control systems - you'll force me to ditch your products.
Huh, that IS a regular lancet device...
Well, at least as someone who has been a Type I diabetic for over 20 years, that's what I consider "regular"...
You just (mostly) described the Dexcom G4.
Sensor wire that effectively acts as a fuel cell powered by glucose is embedded under the skin for 7 days. (measures interstitial fluid glucose concentration instead of measuring blood directly). On top of the sensor wire is a small clip that a transmitter clips into. This periodically samples data and transmits it with a very low-power RF transmitter (TI proprietary protocol) every 5 minutes. 6 months battery life for the transmitter.
The new G5 system uses BLE, which takes battery down to 3 months despite being physically larger. :(
Getting a sensor to last past 7 days is possible, but it becomes a game of chance. Past 7, risk of infection/scarring/biofouling increases. Longest I've ever worn a sensor was 13 days and honestly I'm not doing that again (that site is healing more slowly than I'd like...)
CGM's such as Dexcom's G4 are pretty close to this. The main disadvantage is you need to insert the sensor under your skin once every 7 days... But then fingersticks are only needed for calibration purposes after that.
Well technically you're not supposed to make treatment decisions without a confirmation fingerstick, but... Most diabetics including myself will go for the carbs if there's any possibility the CGM is correct when it says 55.
As a diabetic, I'm actually not too impressed. Remember needleless injectors? Yeah, they do exist and are still in use in cases where people want to give mass vaccinations in an assembly-line fashion, but they're actually much more painful than needles. This patent sounds a LOT like a needleless injector. All of that mechanical complexity is going to make it significantly larger (and hence less convenient) than a traditional lancing device.
Its benefit is minimal since fingersticks are on their way to being relegated to being a calibration source for CGM systems. I believe Dexcom's goal is to reduce from 2 calibrations per day to 1 with the G6. Admittedly, I still usually do 3-5 fingersticks a day, but I used to do 5-8, more if I suspected my bloodsugar was being wacky.
From one diabetic to another - under the assumption you're Type I - the Dexcom G4 was a life-changer for me. I would absolutely recommend it to any Type I diabetic. Being able to see my bloodsugar simply by looking at my watch (xDrip + NightWatch + Moto 360) is amazing.
Honestly, the complexity and description of this really reminds me of those needleless injectors. They're kind of notorious for bruising and actually being more painful than a fine needle - which is why no one with diabetes (including myself) use them. There's no way anything involving air pressure and vacuum barrels is going to be smaller than most lancing devices. It could be useful for mass high-volume testing in hospitals or something... But even with the removal of needles there are so many contamination concerns still.
Also, in general, fingersticks for diabetics will eventually be relegated to being a calibration reference for CGM systems like Dexcom's G4/G5 (I believe Google Life Sciences is partnered with Dexcom now...) Technically you're not supposed to use a CGM to make treatment decisions without a fingerstick, that said - many diabetics (including myself) do make treatment decisions based on their Dexcom. You can make this system as convenient and painless as possible, it's not going to replace an automatic reading every 5 minutes.
There were two reasons I bought a PS3 back in the day:
1) Final Fantasy XIII -- OOOOPS. Epic fail there.
2) Sony seemed to be doing a good job of atoning for their past mistakes with DRM and rootkits... The PS3 did run Linux for a while after all, and even after the OtherOS fiasco, they were overall doing better. The PS3 was a fairly open or at least "standards-based" system - standard USB peripherals, mostly standard Bluetooth profiles. Overall, I think that under Kaz Hirai, Sony has for the most part been moving far away from their old shenanigans of old. (Of interest: Sony's previous CEO rose up through their media/film divisions. Hirai rose up through the consumer electronics/computer entertainment division.)
I was quite happy with my PS3, which is why I went for the PS4 and I have no regrets. That said - if everyone I knew gamed on Xbox One and I played more multiplayer games than just Destiny, I would consider an Xbox. (I basically played no multiplayer games prior to Destiny, and have overall been lucky to find enough friends that play it on either console to find people on the same console I own.)