Schneier on Security
A blog covering security and security technology.
« Full Extent of the Attack that Compromised RSA in March |
| Another ATM Theft Tactic »
October 28, 2011
Friday Squid Blogging: Video of Kid Eating Squid
It's hard to tell if he likes it.
As usual, you can also use this squid post to talk about the security stories in the news that I haven't covered.
Posted on October 28, 2011 at 4:25 PM
• 31 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Shoes with GPS receivers hidden in the heels to go on sale soon. They come with some kind of software support that can alert you when the receiver leaves a designated zone. This is of course to be used strictly for humanitarian purposes such as tracking Alzheimer's patients.
That article has the diagram, but the AFP version has the better quote:
"The primary reason is that paranoia is a manifestation of the disease," Carle said. "If you put something on someone with Alzeheimer's that they don't recognize, they remove it. If it's a wristwatch and it's not their wristwatch, they will take it off. So you have to hide it."
I think most people would insist on wearing their own wristwatch...
Two follow-up articles on issues Bruce has posted on recently.
Search-Engine Land deconstrusts the Google HTTPS change and argues the change isn't really about consumers at all but rather about stifling competition in the advertising market.
The second article follows up on the issue of data privacy in social media, in this case the use of social media data by third parties. The particular issue here is academics and law enforcement teaming up to detect "psychopaths" from social media postings.
Finally, the US Department of Defense looks at how "user narratives" (i.e, propaganda) are used in developing frameworks for dealing with security issues.
Simple question folks,
Has anyone ever used Gmail to provide time stamping of documents, say proving one's authorship for example.
I just wonded so, since gmail (or any other online email svc) is outside of one's control, its timestamping could be considered official.
As an exemple, I would send a Word doc to myself in Gmail and then be able to demonstrate I wrote such document, as the date would then be unalterable
Just a thought...
I like the psychopaths article. Because it gives me an idea for creating pseudonyms so that I can acquire some new Facebook targets, umm, I mean friends.
@Daniel: unfortunately, what most people will take away from that article is that people who say uh and umm a lot are psychopaths. That's the problem with any psychological and scientific information in mass media.
Breaking news: Bruce post from the 24th regarding Blue Coat was correct. According to this WSJ article, "The appliances do have Blue Coat service and support contracts. The company says it has now cut off contracts for the devices."
"Has anyone ever used Gmail to provide time stamping of documents, say proving one's authorship for example"
I actually know of a company where one senior person so distrusted those around them because of the behaviour of the MD they did everything by Email and BCC'd it to their GMail account.
So if a meeting was held even around the water cooler they would type up their version of the minutes and EMail "for comment / correction" to the other attendies and whenever an Email arived from another employee they would reply even with just "thanks for the info" just to get it all into GMail.
When the "odd traffic" was seen from the out going router logs, the brown stuff hit the fan in biblical measures and for well over forty days and forty nights.
And you know all the stories about "a woman scorned" and "bunny boilers" these would be a side show compared to what happened to the senior person. They were accused of theft summarily dismissed, had the police sent around with search warrents for "stolen equipment" had private investigators sent after them and a whole lot more all of which ended up in several court cases (which the senior person eventually won due in part to the copied EMails).
But the blow back did not stop there, the company effectivly severed it's internet connection for general employees, one or two others who had spent a bit to much time on face book etc either had their collar severly felt or were shown the door. The result was carnage, which did not stop, employees felt threatened, and stoped communicating in any real way, good employees including a couple of directors left for other jobs in short order and the company went into near terminal decline and the shareholders and board sacked the MD.
The senior person meanwhile having lost other jobs due to having to fight the court cases finally set up their own company and took most of the business away from the other company finally driving the final nail into their coffin. They also ended up employing half a dozen of the good people who had left the other company.
So from the senior persons point of view in the end yes it was a good idea as it gave them the push to start out on their own and provided the evidence that protected them from the various court cases brought against them and to win their own cases against their former employer.
Would I recomend it no, not because the collateral damage was extream, but because there are other ways to achive the same objective without having to put sensitive information at risk in the hands of a third uncontrolable self interested party.
@ A blog reader,
"On the topic of security, has anyone considered the issue of security vs. user control that may be raised by the "secure boot" feature of UEFI(Unified Extensible Firmware Interface) technology for PCs."
Yes I have, so has Nick P and a couple of others including Ross J Anderson over on the Cambridge Labs lightbluetouchpaper.org site.
Also it appears the Googles director of public policy is having a good hard think on the human rights aspect of IT which UEFI clearly breaches.
Have a look at last fridays squid page, I left a few links there a couple of days ago.
The problem is currently there is very little hard info on UEFI and this makes it difficult to comment on other than to make warnings from history about the past conduct of those currently involved (MS & entertainment IP holders in particular).
I'm thinking that Bruce might just blog about it when information on it firms up a bit.
My personal view is it won't actually do very much for user security or stop malware / phising attacks etc, but it will do an awful lot for "OS Vender Lock-in" and "IP licencing".
My reasoning is somewhat long but to put the malware into perspective, it comes in two basic forms, the first is in native executable code, the second is via interpreted script languages in applications. In the later case this usualy runs at the users behest so is in effect "normal behaviour" it's thus a job for the applications in built security not that of the OS or other things the scope of UEFI is likley to cover.
This is simply because most exploits against individual users are to do with sending out data be it for financial transactions or spam which in many cases look just like expected traffic to the OS. Likewise exfiltration of corporate data in APT type attacks. In both cases the attacker does not care if they use native code or scripts to achieve their objective.
For "secure boot" to work on malware then each and every application will need to be securly written in a way that is atleast as secure as the underlying OS which means data and memory segregation and message passing control which is a very big chunk of code to get right.
Also at the application level in say a web browser this will break so many "web applications" that it is unlikley to be done in web browsers...
Now if you look at "media players" "secure boot" will be effective by migrating a small part of the functionality into the OS. For instance take a sound file if it's format is such that it has an identifing header and an encrypted body, when the application plays the file it does not care about if the file is encrypted or not nore does it care about encryption key handeling, it just sends the data to an OS stream, the OS reads the header and puts in the appropriate decryptor in secure memory and pushes it into the stream the OS also gets the appropriate decryption key via the secure process. The decrypted data then gets sent directly to the D-A converter or mixer input that again runs in secure memory if the data needs to go to another chip it can easily be obfiscated via another encryption scheam before finally exiting out of the last chip in the chain as an analogue signal. Obviously this last chip could be in an entirely seperate device such as a home cinema set top box etc or even in the speaker enclosure. It would also alow for a unique identifing watermark to be added such that if you did re-convert the analogue signal back into digital form it stands as a hidden witness against you.
It looks like Quantum Crypto has had another kick in the pants,
Put simply a weakness in the practical implementation of the (John) Bell Test enables hackers to fake the results and thus convince the detector circuitry that quantum entanglement is happening thus the communications are still secure.
The problem the hackers have exploited is something called a "Bell Test Loophole" ( http://en.m.wikipedia.org/wiki/... ) basically all practical implementations of the Bell Test have to this point suffered from "loopholes" of one form or another where it is expected that some test results are to be missed due to "imperfections" in the test setup.
However there are differences in opinion amongst physicists as to if the loopholes are just equipmently deficiencies or if there is something more fundemental behind them.
Experimental physicists have stated on repeated occasions that a loophole free test can be expected any time soon (see ). However others point out that logicaly it is possible the Quantum Physics itself precludes this from ever happening (see ).
If the latter view point is found to be true then to all practical intents Quantum Cryptography as we currently implement it "probably" won't be unconditionaly secure.
However as I've said before QC is a nice idea but has a whole host of problems when it comes to practical implementations.
 , 2003: R.D. Gill : "Time, Finite Statistics, and Bell's Fifth Position" : http://arxiv.org/abs/quant-ph/0301059
 R. García-Patrón, J. Fiurácek, N. J. Cerf, J Wenger, R. Tualle-Brouri, P. Grangier : "Proposal for a Loophole- Free Bell Test Using Homodyne Detection" : http://arxiv.org/abs/quant-ph/0403191
 E. Santos : "Bell's theorem and the experiments Increasing empirical support to local realism" : http://arxiv.org/abs/quant-ph/0410193
I'm not even sure that article counts as scientific information. It amounts to "people who score high on this one test which is not fully predictive tend to score high on this other test". There isn't even a comparison with people who score high on the PCR and aren't in jail. Community is known to affect speech patterns.
I have. There was a slight, important difference: I hashed it with SHA-256 & timestamped THAT. This means anyone reading can't know beforehand what it was, but I can always prove what it is later. There are online timestamping services too if you need them.
@ a blog reader
"he problem is currently there is very little hard info on UEFI and this makes it difficult to comment on other than to make warnings from history about the past conduct of those currently involved (MS & entertainment IP holders in particular)." (Clive)
"My personal view is it won't actually do very much for user security or stop malware / phising attacks etc, but it will do an awful lot for "OS Vender Lock-in" and "IP licencing"." (Clive)
Pretty much my view on the subject.
"For "secure boot" to work on malware then each and every application will need to be securly written in a way that is atleast as secure as the underlying OS which means data and memory segregation and message passing control which is a very big chunk of code to get right." (Clive)
I agree with the principle. A proper security architecture might be able to work with poorly written apps. However, the app will certainly need to be written or structured in a way that leverages the underlying security architecture. Most apps aren't. Additionally, both POSIX & the Win32 API are inherently insecure due to covert channels. Every "secure" UNIX project required modifications. And that was the older, simpler API.
On the subject of media players, the Turaya security kernel I mentioned in the past was designed partly for this. It's a big market and any security architecture will inevitably be adjusted for it.
Perseus Security Framework - DRM Use Case
Even the OKL4 embedded kernel is partly designed for this in that a major use case is isolating GPL'ed code from proprietary code so the proprietary license can be kept.
@Thomas -- thank you for posting the XKCD link, which is what I originally wanted to do but missed as I was out all day yesterday :-)
@Louis -- yes, you can use a service like that much like the old mail-a-postal-copy method; the problem I'd imagine is that everything is hackable, but maybe gmail AND yahoo AND hotmail and so on, or better yet have an escrow service set up such a box for you that you can't access
@Cliive -- of course sending out private copies of corporate communications would blow up like that, but I think that Louis wasn't talking about sending company email out of the company
And, finally, the squid enjoyment of the day:
One of the PKI RFCs has a standard for timestamps. I don't remember the details - I know you give it a hash and it returns a signed copy + timestamp. The server should also provide a way to query for the signed timestamp later so the other party doesn't have to trust the copy you gave it.
I don't recall if you sign the hash before submitting it.
@Petrea: exactly. Mass media articles reporting on studies or research, or just speculation such as this one are sometimes taken as fact or gospel by the public. In this case, folks might pull out a few details and start playing "who's the psychopath" with their coworkers, classmates, and employees.
@ Natanael L
Yeah, those where the kinds of services I was referring to. If mutually distrusting parties are involved, the best scheme is a linking-based scheme. Most of the companies you referenced seem to be using a PKI or database type scheme, which is less trustworthy. It's best to use companies that go with the X9.95 standard & use its long term integrity provisions. Like these:
@Nick P: I've seen some where the hashes from documents are "chained" with timestamps in such a way that it is possible to prove that a certain hash was enterd before date X. It simply requires that you publish the "main" hash from time to time together with the hashes that went into it.
Seed number (random)
Day one: Hash(hash(customer data 1)+hash(customer data 1)+(...)+seed)
Day two: Hash(hash(customer data 1)+hash(customer data 1)+(...)+hash from day one)
And you publish that in a verifiable way (hashes only, then, not customer data). You can then not fake a hash being older than it is, since you can't mess with the chain of hashes.
(Bitcoin use a similiar concept, the "block chain".)
Oops, I forgot the timestamps.
Seed number (random)
Day one: Hash(hash(customer data 1) & timestamp 1+hash(customer data 1) & timestamp 2+(...)+seed)
Day two: Hash(hash(customer data 1) & timestamp 1+hash(customer data 1) & timestamp 2+(...)+hash from day one)
So that's how it works.
If they one day publish something fishy, it's public and you can point it out and simply stop trusting them.
If they follow this scheme, it's secure.
Meh, now I forgot to edit back the customer data numbers (should be 1 & 2, not 1 & 1). But you get the point.
@ Natanael L,
"You simply require hash was enterd before date X. It simply require that you publish the "main" hash from time to time together with the hashes that went into it."
And thereby hangs the problem...
By publish the original idea suggested posting an advert in "printed newspapers", which as more and more newspapers are now going on-line will nolonger work because the web pages are far from immutable. Thus you get back to the DB problem...
The problem for timestamps and many other protocols has always been and will remain how to find and ensure a cheap and unimpeachable witness, that is beyond reproach by all interested parties, not just for today but anything upto a 1000years (currently the longest types of contract I'm aware of for land leases).
@Clive Robinson: That got me thinking about a P2P timestamping system with "official" organizations taking part as nodes.
It would pretty much be like bitcoin with it's blockchain, but all clients can throw in their own regular hashes.
They will quickly (!) spread through the entire network and will be stored with given timestamp + time of receiving them.
The "official" nodes are just like any other, but they are ran by (more or less) trusted organizations that you can ask when they first saw hash X.
Ask many of them and you've got something you can trust. You can also locally verify the minimum age of anything in the network that you've received.
If you add signatures you can make your hashes easier to find (public key = "tag" to search for) and add some level of proof that the hash is yours (although that can also be solved by putting the document with a .pgp signature file in a zip file and hashing that, and the file is likely to have your name in it).
So - to guarantee a cheap witness, the p2p timestamping client is free and don't require much resources. That means that it can probably run on smartphones, preferably also with low data use.
To guarantee unimpeachability, there's a ridicolous amount of them. Just pick one that already were in the network when you published the document (so that they can prove it's age) and that has a flawless reputation (works due to the block chain design - from time to time the entire network will agree on a "main hash" that is a result of all previously entered hashes - and all hashes being available to everybody).
To guarantee they are beyond reach - it's running on the internet! Put some nodes on Tor, some on I2P, some on any other anonymizing network you can imagine, let some use anonymizing mail proxies, etc...
And of course, there's will be whole bunch of them in every country. And maybe even in space!
"not just for today but anything upto a 1000years"
Eh... I don't think we have any hashing algorithm strong enough...
Also, if we had that - can you ever realistically trust the precise age of anything digital for longer then one lifetime?
Because as soon as it's more then a lifetime old, the people that were there aren't alive. Can you trust that the people now could trust the people before them well enough to know that they in turn could trust the people before them well enough that they in turn ... all the way to the original people.
But if you're willing to accept the risk of collusion, there's still the fact that it's distributed, so if every source you find agree, is that good enough? But "every source" after 1000 years might be just two agencies from the same country... (hence the collusion problem)
"Video of Kid Eating Squid"...
hmm for some reason I thought that referred to a squid that likes to eat kids.
The following line from this article caught my eye, "News 13 has learned the FBI is still trying to crack the encrypted computers that investigators seized from Garcia's home and UNM office."
Well, hmmm. Seems the president of the university was smart enough to encrypt his computer before he started his prostitution ring. That's actually rather shocking. Methinks the FBI might be trying for a very very long time to decrypt his hard drive. Wonder if he used truecrypt.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.