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…
The House Judiciary Committee held hearings on encryption last week. FBI Director James Comey spoke on the first panel, Apple General Counsel Bruce Sewell, Manhattan District Attorney Cyrus Vance, and I were on the second one. I took a technical viewpoint on the Apple case and on security more generally; my written testimony is at: http://judiciary.house.gov/_cache/files/b3af6e9e-b599-4216-b2f9-1aee6a1d90cd/landau-written-testimony.pdf Some of the ideas (e.g., security risks of Apple developing the requested software) will be familiar to RISKS readers, but other aspects will probably be new (this includes discussion of phones as authenticators and how the FBI might respond to the issue of encrypted and secure communications and devices). And for anyone who is really into it, there's also video of the full five hours of testimony: http://judiciary.house.gov/index.cfm/2016/3/the-encryption-tightrope-balancing-americans-security-and-privacy
Transcript of speech by Robert Hannigan, Director GCHQ, as delivered at the Massachusetts Institute of Technology http://www.gchq.gov.uk/press_and_media/speeches/Pages/hannigan-speech-at-mit-front-doors-and-strong-locks.aspx [This is worth reading. PGN]
This is a very nice summary analysis by Richard M. Thompson II and Chris Jaikaran, dated 3 Mar 2016, on the current situation. http://www.fas.org/sgp/crs/misc/R44407.pdf
Muckrock has published a Primer, and advice, on doing Apple vs. FBI Freedom of Information Act (FOIA) document requests, to help better understand the FBI, Apple, and the fight over keeping devices secure while allegedly maintaining national security. * Classified info, and how to seek out what we can find out. * Law Enforcement Practices, and using court precedents to find out more info. * While NSA 3605 is broad, they've got around that in almost 50 cases. * Links to legally accessing other US gov agencies with secrets from uninformed FOIA requests, like FBI practices. For example, you can see how many iPhones and other Apple products the NSA has bought. https://www.muckrock.com/foi/united-states-of-america-10/nsa-contracts-with-apple-inc-8808/#file-18790 https://www.muckrock.com/news/archives/2016/mar/02/applevsfbi-sets-tough-foia-fight-truth/ Muckrock https://www.muckrock.com/questions/ is a collaborative news site helping people find out about the US federal state and local government via FOIA requests. Getting answers to FOIA requests probably take longer than it takes for the final court ruling on this battle. Here are some other recent Muckrock news updates: https://www.muckrock.com/news/archives/ [Currently the Muckrock website looks nicer, cleaner, and more readable in Chrome than it does via IE.] [Chromatic, not IEtrogenic? PGN]
Spencer Ackerman, *The Guardian*, 8 Mar 2016 http://gu.com/p/4hcy2/sbl
France's lower house of Parliament has approved a measure aiming to give prison sentences to technology company executives who refuse to give data to investigators in terrorism-related cases http://www.usnews.com/news/business/articles/2016-03-08/french-lawmakers-vote-bill-to-make-tech-firms-unlock-data The bill, adopted Tuesday by 474 votes to 32 in the National Assembly, will now have to be debated by the Senate. One measure would punish executives in companies like Apple and Google with a fine of up to 350,000 euros ($386,000) and a five-year prison sentence if they deny prosecutors access to a suspect's encrypted data.
That's not what *The Register* headline or what the article says! [See previous item! PGN]
http://jcarlosnorte.com/security/2016/03/06/hacking-tachographs-from-the-internets.html It is possible to monitor and control float trucks, public bus or delivery vans from the Internet, obtaining their speed, position, and a lot other parameters. You can even control some parameters of the vehicle or hack into the CANbus of the vehicle remotely. Those vehicles have a Telematics Gateway Unit (TGU) device and a 3g/4g/gprs/lte/edge/HDSPA modem to connect to the Internet, with a public I.P. address. There are thousands of TGU connected to the Internet, with no authentication at all and with administrative interfaces through a web panel or a telnet session. Imagine the fun hackers will have with self-driving vehicles. [The CANbus on can(ni)bus—with a u for an i instead of an i for an i? PGN]
TL;DR: Mitre controls CVE. Mitre is not giving out CVE assignments. Many people are giving up, and in some cases not even bothering to disclose research. The risks are obvious, discussing vulns without CVE's is annoying and error prone, and people giving up and not releasing research is obviously even worse. CVE is too important to our industry to allow it to fail. http://www.openwall.com/lists/oss-security/2016/03/08/2 http://common-vulnerabilities-and-exposures-cve-editorial-board.1128451.n5.nabble.com/Regarding-the-Distributed-Weakness-Filing-system-td123.html
http://9to5mac.com/2016/03/08/ios-apps-snapchat-harvest-credentials/
The infected software affected a relatively small number of people over the weekend, but it pierces an image of safety long enjoyed by fans of the brand. http://www.nytimes.com/2016/03/08/business/mac-ransomware-attack-exposes-vulnerability-of-apple-users.html
Kristen Clark (*Miami Herald*), in *Bellingham Herald*, via NNSquad http://www.bellinghamherald.com/news/news-services/article62301292.html State senators in Florida overwhelmingly approved a proposal Wednesday to allow high school students to count computer coding as a foreign language course, although questions linger about whether the two subjects should be considered one and the same. The state Senate passed the bill by Democratic Sen. Jeremy Ring on a 35-5 vote. What morons. Promoting computer skills is great—equating them to foreign language skills is the kind of crap that only idiot politicians could come up with.
This may seem to be ridiculous or brilliant, or both at the same time. In that the *art of coding* is not a language, there is a type mismatch in the subject line (coding per se vs code). This might result in a confusion between just studying a computer programming or specification language, as opposed to actually knowing how to use it—e.g., software engineering. But that may be too subtle for the Legislators. Although there are syntactic, semantic, and grammatical similarities between programming languages and natural languages, there are also significant differences: * Natural languages are typically riddled with AMBIGUITIES and PROFANITIES. They are frequently misused and often misunderstood. They are continually evolving based on common usage and long-established dialects. They are not created initially by experts (e.g., linguists)—except for Esperanto. (Puns are plentiful.) * Programming languages are supposed to be UNAMBIGUOUS, but often nonintuitive and prone to bad programming practice and bugs. They are created by individuals or committees, and hopefully standardized to avoid radical differences among different compilers running on different hardware. (Puns are typically rare, confusing, easily ignored, or totally out of place.) At least the Florida Senate did not think that study of computer languages would be on a par with studying English (which may seem like a foreign language to some native speakers of the language. However, it might be interesting to hear legislators' arguments relating to which functional and declarative languages are in scope for credit. Pascal might be favored instead of French, and Euclid as a substitute for studying Greek. Ada would certainly have a following among literature students of English (Lovelace) and Russian translations (Nabokov), as would Oberon (Shakespeare). Astronomy students might prefer Algol. LISP might be considered non-PC. In any case, parents will be required to sign a waiver acknowledging that out-of-state or private colleges might not honor the credits as a foreign language. Natarajan Shankar responded to me: “In what might be the first of the flurry of emails, here's an interesting article on this topic:'' www.vox.com/2016/2/17/11037380/code-foreign-language-florida
The U.S. Supreme Court rejected an appeal from Apple, and left intact a ruling, that the company conspired with publishers to raise the prices of electronic books. Apple will have to pay out $ 400 millions to 23 million consumers who overpaid, and $ 50 millions to reimburse court costs of the people fighting Apple. http://www.npr.org/sections/thetwo-way/2016/03/07/469522666/supreme-court-denies-apple-s-appeal-on-e-books-triggering-millions-in-payments http://www.wsj.com/articles/supreme-court-turns-away-apple-appeal-in-e-books-antitrust-case-1457362484 http://www.emergencyemail.org/newsemergency/anmviewer.asp?aS05
In the current brouhaha over access to a PIN-protected iPhone, I find it personally surprising that Apple has not gone the extra step of increasing security by providing a common feature on burglar alarms: a "Duress" code. Simply put, many alarm systems have two codes, a password indicating a valid access, and a duress code which indicates that the person attempting access is under duress of some sort (e.g., is in a threatening situation). In the case of iOS, such a feature would allow a person to "cooperate" while safeguarding the contained information. Enter the duress code, and the device could activate the time lockout feature or alternatively, wipe the encryption keys, rendering the information inaccessible. This is hardly a novel concept. As I have mentioned, duress codes (negative authentication codes, if you will) have a long history in communications and alarm systems. As an example, many communications systems used by field operatives have a feature of added data to confirm authentication. Send the wrong authenticator, and the recipient is instantly aware that the operative has been compromised. The UK SOE used such features, as did other similar organizations. Similarly, bank alarms have been described as having such features (see Haley's novel "Moneychangers has a reference, as I recall). Bob Gezelter, http://www.rlgsc.com
> This whole line of reasoning is so wrong on so many fronts. Glad you approve :). > The reason that the FBI is requesting Apple to "break into" the iPhone in question is because Apple has ALREADY CREATED the backdoor into the device that permits them to do this. Actually, no. The crux of this whole case is exactly that such a backdoor or tools to establish one do not exist and thus need to be created (assuming this is possible, because that is an as yet unaddressed variable - there have been some suggestions as to methodology but that does not guarantee success). In effect, Apple is asked to undo the very security it spent years achieving. > If Apple had not done so, there would be no way for Apple to comply no matter what tantrums anyone decided to throw. Maybe it's worth reading the original order, all the fun details are in there. It's also a good idea to verify the facts your reasoning depends on, as there is a strong suggestion that you have never been near an iPhone and the way it makes backups. Computers have to authenticate to the iPhone before they gain required access to make a device backup. The days that you could just jack in any computer and copy the data are long gone. > Just as Apple has created backdoor access for themselves to turn over backups and so forth stored in iCloud (the definition of "Cloud" being, of course, Third Party operated computer system over which the data owner has no control or influence over the security of what is stored there). iCloud <> hardware encoded security. Maybe it's an idea for you to review how Trusted Computing works because we are in essence dealing with the same idea of a TPM baked into the chipset, which prevents the data from being accessible once lifted out of the device as it is salted with whatever is hiding in the chipset. It's not exactly a *new* idea, the challenge is to make it actually work, and being in control of your own hardware rather helps. For the iCloud they just had to do a password reset.
Please report problems with the web pages to the maintainer