Posted on 02/20/2016 10:09:42 PM PST by Swordmaker
According to Bloomberg News, the White House convened a secret meeting around Thanksgiving, after agreeing not to seek legislation to force companies to install backdoors in mobile devices that encrypt data, to work secretly to do it through other means.
Apparently, "other means" may include what we are seeing with the Apple v. FBI Court Order.
Link only due to copyright concerns:
Secret Memo Details U.S.'s Broader Strategy to Crack Phones.
i answered your question so your turn to answer mine. first.
What part of "The KEY IS NOT STORED ON THE DEVICE" do you fail to understand?????
How many times do you have to be told that very simple fact before it sinks into what is becoming obvious is a very THICK SKULL?
This is one more thing you think you know that you don't.
The UID is in ROM, so says Apple. Their firmware accesses it. You yourself said:
The UID, a Device Group ID (GID), and the user’s input passcode all make up only HALF of the AES key. The other HALF is made up of initially read random inputs from the camera, microphone, and accelerometer, as well as other sensors at the first startup which are combined by an algorithm and then stored for use thereafter. Those stored random inputs are combined with the UID, GID, and user’s Passcode, all entangled to actually create the large alphanumeric and symbol KEY for the encryption, from which a comparison HASH is made and stored.
http://www.freerepublic.com/focus/news/3399810/posts?page=84#84
> “The KEY IS NOT STORED ON THE DEVICE”
Really? Apple says otherwise. In fact, YOU said otherwise:
The UID, a Device Group ID (GID), and the user’s input passcode all make up only HALF of the AES key. The other HALF is made up of initially read random inputs from the camera, microphone, and accelerometer, as well as other sensors at the first startup which are combined by an algorithm and then stored for use thereafter. Those stored random inputs are combined with the UID, GID, and user’s Passcode, all entangled to actually create the large alphanumeric and symbol KEY for the encryption, from which a comparison HASH is made and stored.
http://www.freerepublic.com/focus/news/3399810/posts?page=84#84
If you are unable to discuss things civilly then the discussion is over.
He's for Rubio.
Or did you mean Tim Cook?
Those who desire putting data beyond the reach of law should be careful what they wish for.
In the current case, the FBI already has all the iCloud data. Apparently, iCloud data isn't secure unless you encrypt it yourself before uploading!
Problem is, the iCloud uploads ended six weeks before the jihad event. Not clear why. Did Farook turn off iCloud backups? Was the phone never able to upload for some other reason (if that was the case, why did Farook bother to carry the phone?)?
San Bernardino County muddied the waters nicely by resetting the iCloud password shortly after the event (allegedly at the FBI's request). That blunder enabled Apple to claim the phone might have synced if brought into a familiar WiFi network, if only the password hadn't been reset. Which, of course, is guano if the phone's reason for not syncing was because Farook had configured it not to sync!
Do you have trouble reading and comprehending what I wrote as well?
" Those stored random inputs are combined with the UID, GID, and user's Passcode, all entangled to actually create the large alphanumeric and symbol KEY for the encryption, from which a comparison HASH is made and stored.
No, Ray76, Neither Apple, nor I, ever, said the KEY was stored on the device. Nor did Apple nor I ever say the passcode was stored on any iOS device. Apple has specifically stated that the PASSCODES and KEYS are NOT stored on any Apple iOS devices. I have ALWAYS said only the one-way HASHes of the PASSCODE and the encryption KEY are stored on the device.
A one-way HASH is a numerical representation of the KEY, sort of like a checksum, that is calculated FROM the key and it is ONE-WAY in that you cannot DERIVE THE KEY in any way from knowing the HASH. THAT is what is stored on the iOS device, not the KEY itself, Ray.
If the passcode fails its test ten times the HASH of the real passcode is erased so that all passcode inputs fail and none can ever open the iPhone.
But NEITHER is stored on the device. . . but YOU think these critical vulnerabilities are stored on there. That's what I mean that you think you know so much you really do not know!
Oh, were we having a "discussion"? It did not seem to be a "discussion" from our perspective.
It seemed to us that YOU were lecturing us on how stupid we all were. There didn't seem to be a "discussion" going on here at all. You just ignored anything we responded to you and kept repeating your false claims, even when we showed you, with quotations from the documents, how you were wrong. That's not a "discussion", that's being lectured to by a "true believer" in "his way or the highway." We've had several others who take that approach. They don't have "discussions" either. When one side of a "discussion" claims the other side is lying, and refuses to look at evidence, then it is obvious that there is a propaganda agenda being spread from that side. You long ago passed that point, when you never responded to any points made by any of us, but just kept spouting nonsense, and mis-representing facts.
Apple says “The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor during manufacturing”
The AES encrypt/decrypt system accesses those keys.
Apple says “Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory”
They keys are in ROM. Without those keys the AES engine would be useless.
Apple also says “No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them.” And “Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UID and GID are also not available via JTAG or other debugging interfaces.”
This is a half-truth. Obviously the AES firmware is reading the keys directly. And do note “Integrating these keys into the silicon” - as I’ve said: the keys are in ROM. Just because you, me, Joe down the street, can’t access the key doesn’t mean Apple can’t.
> It seemed to us that YOU were lecturing us on how stupid we all were.
Now that’s a laugh. You have been very abrasive in nearly every post. You tell me that I make “asinine assumptions”, have a “very THICK SKULL”, and so forth.
Your sneering obnoxious tone got old a while ago. Good Bye.
It doesn't mean Apple can, either. If Apple built it right, they can't. At least not without a lot of work.
What is needed is a way to spy on the operations of a chip in the absence of any sort of debugging API, relying solely on the laws of physics to interpret what the chip is doing, what hidden keys it is reading, etc.
Maybe the NSA could pull it off. But that would involve physically grinding away at the chips and observing the chips' operations using electron microscopy, with catastrophic failure a screw-driver slip away.
There is no need to disable encryption. Simply disabling the passcode retry counter and the timer between retries will allow the FBI to brute force the passcode. I’m not the only one to think of the method I outlined in 98, since that post I’ve come upon this article http://blog.trailofbits.com/2016/02/17/apple-can-comply-with-the-fbi-court-order/
Right, so it can't be used. If a phone is sitting in front of me locked, there is absolutely no way I can find out the UID. Thus I cannot tailor the SW to look for it.
That link does not explain how the SW can be tailored to only run on a specific phone. What they have described is a universal update that the FBI could use on any phone.
Here you go again. YOU turn you ignorance and assumptions into a what you term a LIE! You claim something obvious when you've built it out of your misreading, mischaracterizations, and downright IGNORANCE of how the system works to ASSUME you've got the right answer, when people like me, who DO know how it all works, have been telling you, YOU have it WRONG, that you are misapplying terminology, misapplying half-comprehended concepts, or completely misunderstood concepts, to jump to totally wrong conclusion, AND then you lecture us about YOUR rightness, and Apple's either outright lying, telling half-truths, and how we are wrong and YOU are right because only YOU can interpret things correctly! That's why we are disgusted with you.
You are entitled to your opinion, you ARE NOT ENTITLED TO YOUR OWN FACTURDS.
"Integrating these keys into the silicon" does not necessarily mean they are in a ROM as you so simplistically believe, Ray. It is, Ray, entirely possible to burn them into the encryption engine chip and the varying key algorithms into each separate encryption engine processor, which is what Apple has said they've done in their security paper. The reason the cannot be accessed outside the encryption engine is they are INSiDE the encryption engine processor. These are not accessible. Do you get it now?
Do you even have a clue what "The UID and GID are also not available via JTAG or other debugging interfaces" is or means and why it is so important in this context?
I thought not, or you wouldn't be blithering about "reading keys" from the devices. It means these UID and GID which are only PARTS of the final 256 bit AES KEY, which I told you how the device internally builds its own unique final KEY from these key parts among others, cannot even be found or read by very sophisticated external debugging tools used by system design and testing equipment!
"JTAG" is an acronym for Joint Test Action Group:
"an electronics industry association formed in 1985 for developing a method of verifying designs and testing printed circuit boards after manufacture. In 1990 the Institute of Electrical and Electronics Engineers codified the results of the effort in IEEE Standard 1149.1-1990, entitled Standard Test Access Port and Boundary-Scan Architecture.
JTAG implements standards for on-chip instrumentation in electronic design automation (EDA) as a complementary tool to digital simulation. It specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses. The interface connects to an on-chip test access port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts.
The only things that can be read in system memory are the one-way HASHes which are used to check validity of the input passcode and re-calculated final AES KEY. The stored HASH of either, being the answer to a one-way algorithm, cannot be used to derive the original passcodes or actual encryption KEY which were merely the seeds input into the algorithm that generated that HASH. Therefore, HASHes are useless for either unlocking the iPhone or decrypting the data.
I've been explaining this system for years. I'm not new to it.
As I've told you numerous times, the keys to do either of those things are simply NOT stored anywhere on the iOS devices. What is stored is the means to generate the correct key IF the correct passcode is input by the user, and the HASH created by the hidden algorithm matches the stored HASH. If that condition is met, the AES crypto engine will, using another hidden algorithm, RE-CONSTRUCT the correct AES 256 bit encryption KEY from the various stored PARTS, adding the input passcode the user just input, check IT against a stored HASH, and if that checks OK, decrypt data as needed. There is no need to store the passcode or the actual AES KEY.
Your link article is a blogger whom no one has ever heard of before who claims to be a security “expert” but doesn’t know some very basic things about iOS devices such as YOU HAVE TO HAVE USER ACCESS ALREADY TO UPDATE FIRMWARE!
In other words, if you already have the ability to go into DFU mode to install a special firmware the a specially spoofed iOS to bypass the passcode input limits, you don’t need to, because you are already logged in.his entire
His entire proposal is are circular logic house of cards!
There is one extra step missing from this description although it does not change the bottom line. That step is that there is a randomly generated AES key stored in flash. The key that swordmaker is describing is used to decrypt that AES key. Once that AES key is decrypted it is used to decrypt the user's data. The bottom line doesn't change, to create the key needed to decrypt the AES key, the phone needs the hash of the passcode, the UID from hardware (unique and burned in), and an algorithm in flash.
There is one important point about how that algorithm works that points out one of the flaws in the FBI's court order. That is that the UID is only accessible from that code running in flash. A program running in RAM as the FBI requests cannot access it and cannot create the key to decrypt the AES key.
What is the consequence of that? Pretty simple, the phone has to be updated as designed with an overwrite of flash. Apple cannot do what the FBI requests namely run in RAM with no change to flash. They have to update as they always do, run a rather simple program in RAM that overwrites the code in flash.
On the issue of unique id's, swordmaker is correct that there is no JTAG access. Not sure where that came from, but it's a red herring. The UID is burned into HW and not accessible to anything other than code running in flash. The IMEI is from the SIM which can be removed from the phone. The serial number on the back of the phone is the only possible way to add the unique ID to tie the SW to that one phone. That does appear no longer possible in iOS 8, probably kept private for security reasons, but I have seen conflicting info on that.
The real bottom line is that Apple cannot comply with the order as (poorly) written, it is impossible to alter the normal update process (overwriting flash) while providing the functionality demanded.
The first thing to note is key0x89b: "The UID key is used to create a key called "key0x89b". Key0x89b is used in encrypting the device's flash disk. Because this key is unique to the device, and cannot be extracted from the device, it is impossible to remove the flash memory from one iPhone and transfer it to another, or to read it offline. (And when I say "Impossible" what I really mean is "Really damned hard because you'd have to brute force a 256-bit AES key.")"
Just below the author points out "A random key is generated and used as basis for encrypting the entire disk" and "This key is itself encrypted using key0x89b,"
The reason is pretty straightforward. AES is designed for speed and security, and requires a random key. If an AES key is not random, for example if some portion is created from a known quantity, that makes the cryptoanalysts job easier. Thus an AES key cannot be fashioned from such quantities as the UID from hardware, the hash of the passcode, etc. It must be a random number created by a cryptographically strong RNG.
But yet, Apple wants to use the passcode hash, the UID, and other similar values to protect the phone. So what they do is a well known and studied practice. They use those components, UID, passcode hash, etc to create a key encryption key. The perform a more complex form of encryption using that generated (not random) key which would be essentially impossible to cryptoanalyze.
In short, the AES key is random and used to quickly encrypt and decrpyt all the user's contents. Key0x89b is not random but is tied to the unique hardware ID and the hash of the passcode that the user entered. It is used with a much slower but more secure algorithm to encrypt and decrypt the AES key. Thus the phone is AES 256 encrypted and the AES key can only be recovered on that phone with a correct passcode.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.