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…
It's Apple's shareholder meeting day today, so a good time to ponder the FBI iPhone hacking controversy. Here's the best article I've found so far on this topic: http://arstechnica.com/apple/2016/02/encryption-isnt-at-stake-the-fbi-knows-apple-already-has-the-desired-key/ Most of the news articles and TV coverage I've seen about the hack that the FBI wants to force Apple to create, don't fully explain why it's needed. A few of the stories mention the "10-times you're out" problem, where the phone data is deleted automatically after 10 incorrect password attempts. 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. This means that they'd only have to make the clone 1000 times, though there's a 50% chance the PIN will be in the 1st half of the numbers attempted, so on average only 500 attempts will be needed. Sure, making 1000 phone memory clones and testing them is time-consuming, but it certainly can't take longer than the time to sue Apple all the way to the Supreme Court. Apple has estimated that it was going to take 6-10 engineers 2-4 weeks to write and debug the code—assuming 50 hours a week, that's 600 to 2000 hours. https://www.documentcloud.org/documents/2722196-Motion-to-Vacate-Brief-and-Supporting-Declarations.html#document/p22/a279957 On the other hand, the FBI estimates that the time it takes to extract data from a cell phone as 15 minutes. Allowing for 15 minutes of set-up time, and another 15 minutes to upload the memory into a cloned iPhone, you're looking at 45,000 minutes or 750 hours, pretty close to Apple's lower bound on their time estimate. Maybe Apple has already figured this out and isn't really planning on writing any software? They could just make clones and brute-force the PINs. It turns out that it'll take longer than a few minutes to make the 10 attempts. The news pieces haven't been mentioning a further issue about the delays, but the Ars Technica piece I cited above reveals this: "While the first four attempts can be entered back-to-back, the iPhone will force you to wait one minute before the fifth attempt, five minutes before the sixth, 15 minutes before the seventh and eighth, and a full hour before the ninth." Adding in a minute for the 1st 4 tries (actually they take 80ms each), that's 97 minutes, or a little over an hour and a half for the 10 tries. So, if we add in another 97 minutes per phone, that's around 2367 hours for the 1000 clones with 10 time-delayed tries each, a bit over Apple's upper bound time estimate. Apple knows their engineers rarely work a 50-hour week, so if they supply them with some Jolt cola or powershot drinks, they can still probably get it done in a month, or half that if they get lucky with the brute force guesses. Thing is, the FBI already has the equipment to perform physical extraction of iPhone memory at their Cell Phone Investigative Kiosks available for law enforcement use at 80 locations around the country. https://www.rcfl.gov/downloads/documents/cpik-brochure The most popular extraction tool (and the one they are likely using) is Cellebrite's UFED Physical Analyzer, which supports the full range of iPhones, including locked iOS devices with simple or complex passcodes. http://www.cellebrite.com/Pages/ios-forensics-physical-extraction-decoding-and-analysis-from-ios-devices There has to be a bunch of hackers the Government has arrested in the last year that they can ply with dropped charges who can show them how to reinstall cloned memory contents into an iPhone 5C. Or they could just offer to pay Cellebrite to figure out how to do this. And once they know how to clone the memories, they can deploy 6-10 agents from the child porn detail for 2-4 weeks and pay them some overtime to create the clones and run the brute force attacks. 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. Rebecca Mercuri, Ph.D. Digital Forensics Expert Notable Software, Inc. www.notablesoftware.com Copyright (C) 2016 by Rebecca Mercuri All Rights Reserved
Legal and societal hurdles aside, key fragments might look like a few electrons in "the cloud" but in reality storing them requires very tangible physical hardware with electricity bills, backups, cooling, replacement drives, and so on and so forth. Even if this is somehow funded, there's still catch-22: you can either stay Anonymous or apply for the funds to run your key storage operation.
The book "The Victorian Internet" recounts how criminals were quick to
exploit the telegraph for insider trading. For example: the telegraph
outran horse race results via official channels, so it was illegal to send
race results. Criminals resorted to coded messages, which telegraphers
refused to send (when recognized). History repeats itself with this new
attempt at supervision?
https://en.wikipedia.org/wiki/The_Victorian_Internet
Telegrams charged by the word, so businesses economized by using
abbreviations. Some of those codes were almost Huffman encoding (remarkably
similar to today's text abbreviations - LOL?) so only real words were
allowed by the telegraph companies. That resulted in Commercial
codebooks. Citing Wikipedia
https://en.wikipedia.org/wiki/Commercial_code_%28communications%29 "Another
aim of the telegraph codes was to reduce the risk of misunderstanding by
avoiding having similar words mean similar things. Codes were usually
designed to avoid error by using words which could not be easily confused by
telegraph operators." The modern concepts of error detection and
compression were already addressed!
I wonder if the "Central Scrutinizer" is seeded with those codebooks. It's
not far fetched to substitute modern instruments for obsolete commodities.
("Big Brother" is to George Orwell's novel "1984" as the "Central
Scrutinizer" is to Frank Zappa's 1979 rock opera "Joe's Garage")
Creative texting might use unicode for Klingon or Linear-b (the recently
cracked script of receipts and book-keeping: ideograms for objects or
commodities)
Prisons are full of failed codes and obfuscation (as well as well known
codes):
http://www.writeaprisoner.com/vbforum/general-prison-talk/46059-general-us-prison-slang.html
Consider these failed attempts:
1)
Does he have the shirts?
Yes, he has the shirts.
Are they good shirts?
Yes, they're really good shirts.
Fine, I'll take 2 1/2 shirts
2)
Do you have the stuff?
Yea, I got the stuff.
This time, don't forget the bullets for the stuff!
A curious tangent: net neutrality, censorship and astro-turfing/hijacking
social media is over 100 years old:
http://arstechnica.com/tech-policy/2011/05/how-the-robber-barons-hijacked-the-victorian-internet/
How Robber Barons hijacked the "Victorian Internet"
Ars revisits those wild and crazy days when Jay Gould ruled the telegraph
and ...
The meat of this story seems a little contrived to me: > “I hacked your email on the plane and read everything you sent and > received. I did it to most people on the flight.'' He had verbatim detail > of a long email that he repeated back to me essentially word for word. If I had just committed a crime, especially one which sometimes receives truly draconian penalties, I'd be quite cautious about telling one of the victims about it. Furthermore, while I have not flown for some years, my understanding from RISKS suggests one might be especially careful about doing so in an airport, where the authorities seem to engage in some quite indiscriminate excesses. It transpires that the alleged hacker was "in the row behind me". I wonder if perhaps they employed the Mk I Eyeball to read this reporter's email, something that would be easy to do and also wouldn't risk being shoulder-surfed in turn by other passengers? I suspect what we have here is a case of "reporter hears unlikely story but writes it down anyway".
I had similar problems back in 2001 with a TruTime NTS-100. There's a discussion of it and the solution here: https://groups.google.com/forum/#!topic/comp.protocols.time.ntp/DAhxHPXPqXs So when it started again this month, with the same (ancient) NTS-100 I tried to find any info on the problem since I had long ago forgotten anything about it. Turns out that the thread above has the clue to the solution. For the NTS-100 it is to set the 'YEAR' parameter (F68) to 2015. In the original fix it was to set it to 1996. And... it has to be some sort of parameter setting for the fix since there is no real possibility of updating the 16+ year old device. The reasoning behind the fix seems to have to do with some issues with relative weeks and what date/year the system has last synced with etc. etc. But... it fixes the problem and the NTS-100 is back to replying with correct dates. Bob Rahe, LMIEEE, bob@dtcc.edu (RWR50), Delaware Technical & Community College Computer Center, Dover, Delaware
Please report problems with the web pages to the maintainer