Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
All right now, how many people reading this:
[1] saw a previous version of this message in RISKS-6.34, 13.21, 17.81,
20.83, 23.24, 25.07, and/or 26.75;
[2] still wear a wristwatch instead of using a cellphone or something
as a pocket watch;
[3] have the kind that needs to be set back a day because (unlike the
smarter types that track the year or receive information from
external sources) it went directly from February 28 to March 1;
and
[4] *hadn't realized it yet*?
The smiley face, heart, praying hands and other "emoji" have become the way millions of Internet users playfully punctuate their texts, posts and messages, but for one middle schooler the icons brought the police to her door. The 12-year-old from Fairfax, Va., has been charged with threatening her school after police said she posted a message on Instagram in December laden with gun, bomb and knife emojis. https://www.washingtonpost.com/news/local/wp/2016/02/27/a-12-year-old-girl-is-facing-criminal-charges-for-using-emoji-shes-not-alone/?tid=pm_local_pop_b The risk? Clashing cultures, evolving communication, and misunderstood (or understood all too well) language.
Thomas Claburn, InformationWeek, 25 Feb 2016 via ACM TechNews, Friday, February 26, 2016 In a research paper published Tuesday at the USENIX File and Storage Technologies (FAST 2016) conference, Google researchers called on academia and industry to work together to adapt hard disk drives to current data center needs. Google wants designs that are more affordable, more error-prone, and better suited to collective operation. Google's Eric Brewer says conventional disks are designed for traditional servers instead of large-scale data centers supporting cloud computing. Brewer expects the rate of video uploading to grow 10-fold every five years, and in order to accommodate this massive amount of data, he argues hard disks should be optimized to function as collections of disks instead of discrete devices associated with a single server. "This shift has a range of interesting consequences, including the counter-intuitive goal of having disks that are actually a little more likely to lose data, as we already have to have that data somewhere else anyway," Brewer says. The Google researchers also say security must be improved as new use cases for storage are considered. They say security must be hardened to prevent unauthorized firmware changes and encryption must be adapted to collections of disks through the support of multiple keys, which would make it easier to secure data from different customers in shared disk space. http://orange.hosting.lsoft.com/trk/click?ref=znwrbbrs9_6-eb02x2dd87x065381&
http://arstechnica.com/security/2016/02/asus-lawsuit-puts-entire-industry-on-notice-over-shoddy-router-security/
Author's comment: My latest Guardian column traces the connection between vaccine denial, climate denial, and the denial of ground mathematical truths, like "You can't build a secure system with a back door that only admits good guys" or "You can't hide keys in a computer you give to your adversary." In all cases, the science is largely settled, but policy-makers treat it as though it's controversial among experts. http://www.theguardian.com/technology/2016/feb/24/the-fbi-wants-a-backdoor-only-it-can-use-but-wanting-it-doesnt-make-it-possible
http://nymag.com/following/2016/02/apple-doesnt-care-about-you.html
I liked what you had to share on RISKS, but I think that Apple would be able to take the password brute force one step further, and it's possible that any Apple developer could (namely the FBI or a consultant). There is probably a development tool such as a simulator or virtual machine that could start with the memory state of the phone in custody. I'm sure Apple would have such a tool, but I don't do iOS development so I don't know if one is widely available. If such a tool exists, you could just spawn 10,000 copies of it (in series or some parallelism) and provide the appropriate virtual key presses to each. The first time to do such a task would surely require some setup of the scripts to do the spawning and to get them in the right initial state, but I would imagine that to be less than a few hours. At that point, you're probably only looking at about a small number of hours to simulate/virtualize all of those copies and to run the 4 keypresses on each. Detecting success or not could be scripted, or would be simple to just look at the simulated display to see if it logged in or not. So start to finish, you're probably only looking at 1 person working for one day, but of course, it would have to be the right person doing it.
I agree. Back in the day, when I (and Notable Software) were "Apple Certified Developers" I seem to recall there was such then. I did think about simulating when writing this, but didn't want to clutter up the posting with that. And writing a simulator (if one doesn't already exist) is a lot harder than the work-around they proposed in their court filing. I can see the 10,000 virtual clones existing in the (i)Cloud to save memory. ... Thanks for your message. Rebecca Mercuri.
While Rebecca's note presents a good case, it fails to take into account an important element of the security design of the iPhone. More out of a busman's holiday curiosity than anything, I've carefully studied the five revisions of the white paper Apple has written describing iPhone security. While parts of them are obscure and even in some ways surprisingly inconsistent, one point is very clear: the device's unique ID is burned into silicon in the processor and not readable by anything. (As a former security "expert" I have to say I am very impressed by the security design Apple has come up with.) Quoting from the earliest white paper I've been able to find, dated May 2012, which would apply to the "Subject Device": "Every iOS device has a dedicated AES 256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient." "The device's unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused into the application processor during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed using them. The UID is unique to each device and is not recorded by Apple or any of its suppliers. ... Burning these keys into the silicon prevents them from being tampered with or bypassed, and guarantees that they can be accessed only by the AES engine." Thus, cloning the memory of a device would be useless. The only way of accelerating an attack (brute force search for the device passcode) would be to extract the 256 bits of the UID directly from the silicon; not knowing anything about the technology involved or the current state of "reading" a chip I wouldn't be able to speculate on how easy that is or even if the FBI has the technology to do so. Thus, the fastest rate passcodes could be brute-force searched, no matter what software is substituted for Apple's firmware and software, is 80ms per try, since the "tangling" algorithm is serial and involves repeated passes through the AES chip. I have seen assertions that the passcode in question is 4 digits; I have no idea how anyone would know that. The white paper notes that a 6-character alphanumeric (upper and lower case + numbers) passcode would take 5 1/2 years to crack. The reader can do the math to tell how long, say, an 8 character one, for instance, would take.
Rebecca Mercuri says the link she shared is the best explanation she has seen, for what is needed. Her credentials, and others here at RISKS, are far superior to mine. I was merely a general IT worker. But this debate has been going on for years, long before the latest terrorist attacks and this particular court case. Books have been written on the issues. It is not a simple matter. I think, what she shared, is a good explanation of the DOJ/FBI starting side in the adversarial dispute in the court case which has most recently grabbed MSM attention. Their side has evolved, via additional court filings, as Apple identified problems (flaws, untruths, difficulties) in the initial DOJ/FBI filing, to which DOJ/FBI has responded to the court, and the court has asked Apple for clarification, which has been delivered.. As such, what she shared is not a good picture., since the initial court order had untruths, which later reports have illuminated, and the court filings continue. In my opinion, a good picture is one which shows many sides in perspective, such as this Time Line mountain of links http://markn.ca/2016/02/apple-vs-the-fbi-the-highlights/ This timeline has links to what has been stated by professionals on both sides of the court battle, and larger issues of privacy, encryption, back doors, national security, the constitution, what should be decided by courts, Congress, administration, capitalism. It shows responses to allegations, from which we learn that there are many untruths in what the DOJ/FBI said to the judge, repeated by the article Rebecca likes. In time, we may see responses to Apple position, which are on point, instead of DOJ/FBI characterizing them as marketing policy, which is a form of trolling, unworthy of the government. They should attack the issues, not demonize the defendant. * Apple does NOT have the key the FBI is asking for. They have to engineer it. That will take 6-10 engineers working 2-4 weeks.. In addition, there are implied requirements to sufficiently document the process, so that the rights of a person to face their accuser can be satisfied, if this info is ever used against someone in a US court of law. * Encryption and backdoors are an issue. Any destruction of security for one government case becomes a precedent for many more, and opens the door for ISIS and other adversaries to exploit the security holes for their own ends. Remember the OPM breach? That was made possible by a back door inserted by NSA, which is now all over US government sites. We have not yet been told NSA's reasoning, but reading between the lines, it is reasonable to infer, that they had a fantasy that any security hole they created, could only be exploited by them, and not by the nation's adversaries. We are now seeing the same fantasy in the DOJ/FBI case against Apple. What we have not yet seen is info from Friends of the Court. * She also says it is unlikely for Apple engineers to actually work 50 hour weeks. It is entirely normal in the IT profession for people to work 50-65 hour weeks. In might not be normal at Apple, or in her career experience. In my career, it was not unusual to have crises requiring longer working hours than usual, such as reacting to a crash, implementing a conversion, responding to government auditors. They want that resolved yesterday! We can't get it that fast, but we try to get it as fast as we can. We IT workers are also sometimes motivated to work long hours. Once upon a time, the CEO walks into the computer room at 7 am and asks what I am doing here at this hour (I normally work swing shift afternoon & evening.) I tell him that I have been here all night. We had a hard disk crash & IBM estimates they will be here mid-day with a replacement. They also told me how to work around the magnetic hole to back up whatever we can around the edges of the hole. It is tedious, but I expect to get done with that before the replacement hard drive arrives. No one may use the system until after IBM repair is completed. You might want to give some clerks a day off, those whose jobs require computer access. After this is all resolved, I am going to take the next weekend off. I once worked several months working 2 1/2 shifts, 6 day week, with single shift on the 7th day. That was just over 100 hours a week. It is doable if you are: in good health, no more than middle aged, the stress levels are extremely low, and someone else fixes our food, to maximize sleep time between long work sessions. There are issues with fatigue impairing our productivity. Some companies do a good job of balancing how much extra work load in a rush job is counter-productive, and some managers are oblivious to that dimension.
Thank you for your lengthy response. I'm not sure you read very carefully what I wrote, though. I did not say that this debate is in any way new. Nor did I say that there were not plenty of crypto issues (which was NOT what I was addressing in this piece). I am old enough to remember Clipper Chip. I did not say that Apple workers are unlikely to work 50 hour weeks. I said they rarely work a 50 hour week. My implication was supposed to be that they tend to work a lot longer with the addition of some caffeine. Probably I should have said rarely work ONLY 50 hour weeks. I assumed that any tech-head reading this would understand that most engineers, especially at places like Apple work FAR LONGER than ONLY 50 hour weeks. I did not say that Apple had the key that the FBI was looking for. Nor did I say that there were not untruths in the original testimony and court filings. I was not talking about backdoor exploits. What I was focusing on was a method involving a brute force attack that would allow Apple to avoid writing the code (and then using it, themselves, perhaps, on the iPhone at issue) that they claim could be problematic to their business model. Hope this helps your perspective on trying to decypher what I wrote.
There is an error in Rebecca Mercuri's analysis of the FBI-Apple issue. > Still, the FBI could clone the phone's memory and just use brute-force to > make different attempts on cloned phones. It's just a 4-digit PIN, so > there's only 10,000 different PINs to try. Dr. Mercuri's reference for her post to RISKS appears to be the Ars Technia article that she cited. I suggest that a better reference is Apple's iOS security guide: https://www.apple.com/business/docs/iOS_Security_Guide.pdf A few critical paragraphs are: > "Every iOS device has a dedicated AES 256 crypto engine built into the DMA > path between the ash storage and main system memory, making encryption > highly efficient. > "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 and > Secure Enclave during manufacturing. No software or rmware can read them > directly; they can see only the results of encryption or decryption > operations performed by dedicated AES engines implemented in silicon using > the UID or GID as a key. Additionally, the Secure Enclave's UID and GID > can only be used by the AES engine dedicated to the Secure Enclave. The > UIDs are unique to each device and are not recorded by Apple or any of its > suppliers. The GIDs are common to all processors in a class of devices > (for example, all devices using the Apple A8 processor), and are used for > non security-critical tasks such as when delivering system software during > installation and restore. Integrating these keys into the silicon helps > prevent them from being tampered with or bypassed, or accessed outside the > AES engine. The UIDs and GIDs are also not available via JTAG or other > debugging interfaces. The other critical paragraphs are: > "Passcodes > "By setting up a device passcode, the user automatically enables Data > Protection. iOS supports six-digit, four-digit, and arbitrary-length > alphanumeric passcodes. In addition to unlocking the device, a passcode > provides entropy for certain encryption keys. This means an attacker in > possession of a device can't get access to data in specific protection > classes without the passcode. > "The passcode is entangled with the device's UID, so brute-force attempts > must be performed on the device under attack. A large iteration count is > used to make each attempt slower. The iteration count is calibrated so > that one attempt takes approximately 80 milliseconds. This means it would > take more than 51.5 years to try all combinations of a six-character > alphanumeric passcode with lowercase letters and numbers. FBI can image the phone (phone "cloning" is something else, BTW), but FBI cannot image the secure enclave. If FBI copies the data off the phone and tries 10 passwords, the encryption key in the secure enclave will be wiped. This is sometimes called cryptographic erasure. It doesn't matter if the memory is copied off the phone, it's not the memory that's being erased. There is no way to restore something and try again. There is a way to crack the phone, but it requires the use of exotic technology to extract the unextractable information. Once it is extracted the password can be cracked on a cluster. Each attempt will still take 80 msec, but many can be executed in parallel. At the end of her post, Dr. Mercuri states: > So the FBI v. Apple lawsuit just doesn't make any sense, unless there's > something I'm missing in my analysis or information we just haven't received > yet about this situation. It is quite difficult to understand what is going on in this case from reading press accounts. Many of them contain erroneous information. However, I trust Apple's iOS Security guide, as it predates the current event, and it is written by an organization that has an incentive to get the facts right.
Please report problems with the web pages to the maintainer