Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
News, opinion, advice and research: Chet and Duck (Chester Wisniewski and Paul Ducklin) bring you their unique and entertaining combination of all four in their regular quarter-hour programme.
Chester's been on the road, so this epsiode of the Chet Chat is a couple of days late for logistical reasons.
We apologise for that, but Chet and Duck think it's no less interesting nevertheless!
In fact, this week's main story - the two-in-a-row exploits against Android code verification - intrigued your presenters so much that they resolved to link up and record this show, come what may.
And so, here it is: SSCC Episode #113.
(You can keep up with our podcasts via RSS or iTunes, and catch up on previous Chet Chats and other Sophos podcasts by browsing our podcast archive.)
The news wires have been buzzing with the "master keys" attack, and the "extra field" attack, both of which let you create Android Package files (APKs) that show one set of content to Google's cryptographic verification, and another to the installer.
Chet and Duck explain what happened, come up with some ideas that would have avoided the problem in the first place, explain what to do about it, and wonder how long before the fixes are on your handset.
From Android to iOS, where Tumblr published a version of its app that somehow managed to leave out the part that encrypts your PII before sending it over the internet.
Chet wonders how the average user is supposed to spot that sort of bug.
Nintendo got pounded by crackers who mounted a month-long password guessing attack.
The crooks only got hold of 24,000 passwords as a result (only!), and it looks as though those successes were largely down to using dictionaries of usernames and passwords from earlier hacks.
What to do? Federated identity? Password managers? A slimmer digital lifestyle?
Chet and Duck discuss the pros and cons of various ways to address the problem of password re-use.
And Chet's going to be at BlackHat 2013, and at DEF CON, so be sure to look him up in Vegas and say, "Hi."
Duck won't be there in body but you will find him present in mind and spirit, as he's putting together a special #sophospuzzle for the occasion.
The puzzle will go up on Naked Security, so everyone can have a go, but BlackHatters can enter at Sophos's booth at the trade show and win a secret prize!
(It's a cool secret prize, which Duck lets slip in the podcast, and Chester bemoans being ineligible to win.)
Don't forget: for a regular Chet Chat fix, follow us via RSS or on iTunes.
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
IBM just released an open source software package called HELib.
The HE stands for homomorphic encryption.
Although it doesn't sound terribly sexy or impressive, HELib is actually an interesting and important milestone in cryptography.
HE is also a surprisingly relevant topic right now, with our ever-increasing attraction to cloud computing.
Bear with me, and I'll try to explain.
Imagine that I am your cloud provider, and I keep databases online for you.
Imagine also that I am a security-conscious vendor, so I keep all your data encrypted, both when I serve it up to you, and when I save it to disk.
That's about as good as it gets these days from a cloud security perspective.
? It doesn't matter whether I'm a pure-play over-the-internet cloud provider, or just the manager of the server farm team in your own IT department. The situations are similar, though they may differ in degree: I've got your data, and you have no alternative but to trust me to do the right thing with it.
Now imagine that you want me to search through your data, for example to see how many ACME-WIDGETS were bought by customers called DUCKLIN in the last year.
Traditionally, the process would go something like this:
You encrypt the search terms and upload them to me.I decrypt the search terms so I know what to look for.I decrypt your data (perhaps only record by record, not all at once - that's a detail that doesn't matter here) so I have somewhere to search.I perform the search using the decrypted data.I encrypt the search results, if there are any, and return them to you.
Additionally, you hope that:
I get rid of all remnants, on disk and in memory, of both the search terms and the decrypted data once the search is complete.I don't take advantage of you, since I'm decrypting your data for this search, to sneak in other searches at the same time, whether for my own benefit, or for my government, or for one of your competitors.
There's a lot that could go wrong - for you, at any rate.
Imagine, however, if I could simply take your encrypted search terms, leave them encrypted, search for them directly in the still-encrypted database, and get the same results.
If I can perform calulations directly on your encrypted data, yet get the same results that you get from the unencrypted data, we both win enormously from a security and privacy point of view.
You don't need to give me any decryption keys at all, so you no longer have to trust me not to lose, steal or sell your data. (You still have to trust me to tell you the truth about any results I work out for you, but that is a completely different issue.)
And I no longer need your decryption keys, so I can't lose or abuse your data even if I wanted to.
That's the promise of homomorphic encryption, which we mentioned at the start.
Until 2009, no-one was sure whether homomorphic encryption was even possible.
Then, a Stanford student and IBM researcher called Craig Gentry showed that it could be done, in a PhD thesis entitled simply, "A fully homomorphic encryption scheme."
We weren't home and dry yet, though.
Gentry had what amounted to an existence proof, showing that homomorphic encryption could no longer be considered impossible, but he didn't have a practicable real-world implementation of the concept.
At the time, back in July 2009, well-known cryptographic personality Bruce Schneier praised Gentry's efforts, but pointed out that:
Gentry's scheme is completely impractical... Gentry estimates that performing a Google search with encrypted keywords - a perfectly reasonable simple application of this algorithm - would increase the amount of computing time by about a trillion.
Well, we're now a few steps further forwards, with IBM's release of the abovementioned software package HELib:
HElib is a software library that implements homomorphic encryption (HE). Currently available is an implementation of the Brakerski-Gentry-Vaikuntanathan (BGV) scheme, along with many optimizations to make homomorphic evaluation runs faster, focusing mostly on effective use of the Smart-Vercauteren ciphertext packing techniques and the Gentry-Halevi-Smart optimizations.
With a package description like that, it's obvious that consumer-facing homomorphic encryption tools aren't going to be a click away at the Play Store or the App Store for a while yet.
On the other hand, four years ago we didn't even know whether it would be possible to have homomorphic encryption at all.
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Ancient Roman propaganda poet Publius Vergilius Maro, better known as Virgil, famously had one of his more cynical characters cry out:
If you don't know Latin, but you do know that Teucri refers to the people of Troy, and Danaos to the Greeks, you can probably guess what this is about.
The highlighted words mean, "Don't trust the horse, chaps!"
The thing about the Wooden Horse of Troy, of course, was the question that perplexed Laocoon, the priest who is speaking in the extract above, namely, "Why?"
Of all the gifts you could leave behind, why a giant wooden horse? Why that shape? Why that size?
Laocoon even flung his spear at the horse, by way of science, and noted that it didn't produce the sort of resonance that you'd expect from an innocently hollow wooden statue.
But no-one listened, and it didn't go so well for the Teucri after that.
As it happens, this story is about an App Store program that probably isn't a Trojan Horse - I didn't feel like paying six quid to find out, to be honest - but it is a great example of the sort of story that cries out for an answer to "Why?"
The software is called Redact Secure Messenger, and it claims to fill an important niche by sending "heavily encrypted messages from one phone to another without passing through any central servers."
The first thing that will attract your attention (perhaps not in the way the marketing people intended) if you are interested in cryptography is its claim to be "the world's first totally secure instant messenger application."
Wait a minute! Didn't Blackberry do that years ago?
Didn't Blackberry do secure, free instant messaging so well, in fact, that it got into hot water for it when a giant wave of criminality lashed the UK back in 2011?
And what are the words totally secure doing next to each other? Didn't Alan Turing have something cautionary to say way back in the 1930s about the problems of putative programmatic perfection?
Keep reading, because the story gets weirder.
The company behind this product, which identifies itself on its web properties (that I could find, anyway) only with a mailto:?info@?redactapp.com link, is offering a "£10,000 prize to anyone who can intercept a message" secured by the app.
Actually, that's not what it's offering at all.
It's not anyone, it's not any message, and merely intercepting it is not enough.
To have a crack at the £10,000, you have apply, and then be one of up to 20 people chosen by the company; then you get a chance to try to decrypt a single message that will be bounced back and forth between a pair of phones at an as-yet undisclosed location in London.
Oh, and it gets even weirder still.
When you apply, it's like being phished.
You have to fill in your full name, address, phone number and - wait for it! - upload your Curriculum Vitae (British English for resumé).
All this, even though you are as good as guaranteed in advance not to win.
(If if is, indeed, possible to win, then the app's claim to be totally secure is false.)
If you want to be a gung-ho encryption company with grandiose claims - like Kim Dotcom's MEGA, for example - then you should at least be open about your cryptographic methods, set a clear and public challenge, and be prepared to defend it against all comers.
That's what MEGA did with its bounty programme, and whatever you think of MEGA, of its founder and of its raison d'etre, it nevertheless reflects to the company's credit that it offered bounties at all.
What Redact is doing just invites too many "Whys".
This sort of thing is a bad look for the encryption industry, and we can do without it.
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Every few years, someone reads, or remembers, or rediscovers something we often forget: computer memory isn't volatile, after all.
RAM chips don't lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.
Don't get too excited: RAM contents don't persist without power in a reliable and consistent way.
If you accidentally pull the plug out of the wall before you've saved that fantastic new presentation, don't expect to get it back.
But if you can cycle the power quickly enough, and reboot under your own control from some secondary device, such as a USB key, you might be able to see the ghostly remnants of what the previously-running operating system was up to.
You can guess where this is going.
If you clean boot a computer with a hard disk that's running full disk encryption, or FDE, you can't get anything off it.
Not just the data, but also the operating system, swap and hibernation files are scrambled. Nothing can be accessed without the decryption key.
But what if the decryption key, or a large enough chunk of it, is part of the RAM that didn't fade to grey when you cycled the power?
That can happen, thanks to the phenomenon of left-behind data in RAM.
(The name you'll hear is remanence, a word originally used for residual magnetic fields, and now also used to refer to the not-yet-decayed electrical charge in memory chips.)
And if you cut the power abruptly, you prevent the operating system from taking any emergency shutdown measures, such as deliberately purging critical areas of memory to wipe any active encryption keys.
The latest researchers to rediscover remanence in a newsworthy way are from FAU, the Friedrich-Alexander Universität Erlangen-Nürnberg.
They've turned their sights on Android, building a custom distro of Android Linux called FROST, short for Forensic Recovery Of Scrambled Telephones.
So far, they've only tried it on the Samsung Nexus phone from Google.
That's because they need three planets to align before the attack will even begin to work:
The bootloader needs to be unlocked.The device needs an easily-removable battery.Ideally, the device needs to be at or close to 0°C.
The reason for these limitations are the things that go wrong if they aren't in place.
If the RAM is at room temperature, its remanence is greatly reduced, so it "forgets" much more quickly.
If you can't get at the battery, you can't easily cycle the power abruptly.
If the bootloader is locked, the device will automatically get wiped if you try to unlock it.
The wipe-on-unlock feature is a clean and simple security process enforced by Google, at least on recent devices.
? Android devices support a stripped-down mode called FASTBOOT, which gets its name because it boots up your device in a second or two. A magic chord of keys pressed down at power-up is typically used when you want to engage FASTBOOT's services. It has very limited functionality, but the key features are that it allows you to unlock your firmware, and to reflash it. Locked firmware can't be flashed, for security reasons, and unlocking (assuming your device allows it) it will wipe the device so that your freedom to reflash doesn't come at the previous owner's expense.
The first thing you need to do, when you rediscover remanence and want to use it against a specific device, is to find out if your proposed attack is practicable.
That means loading up memory with something you'll easily find and recognise later, and seeing how well your chosen content survives a power outage.
When a posse of Princeton programmers famously brought remanence into the limelight back in 2008, they used images of Mona Lisa.
The FROST crew picked a more modern mascot, Google's Android robot:
The results weren't terribly convincing at room temperature, given that rebooting the phone quickly by jiggling the battery takes an unpredictable time.
Lowering the temperatures offered improved results, as the authors showed graphically:
(They neglected to label the axes, a peccadillo usually restricted to marketing departments, so we'll have to assume that the X-axis shows reboot time in seconds, and the Y-axis shows the percentage of bits lost. The obvious conclusion: take less than a second, and head towards freezing point.)
The authors eventually settled on popping the target phone in a freezer at -15°C for an hour. They laconically point out that they can't promise you that your phone will survive, noting that "damaging the phone is your own risk, but we haven't experienced any problems yet."
? A word of warning. If you live somewhere warm and humid, such as Singapore, Dar es Salaam or Brisbane, your phone will rapidly start to collect moisture when you remove it from the freezer. If you're fiddling with the battery and the buttons of your phone to try to orchestrate this attack, you won't be able to dry it off as you go along. As the FROSTers say, damaging the phone is your own risk.
To find the FDE decryption keys in memory (Android uses AES encryption), the authors used a modified version of a program called aeskeyfind, originally created for the 2008 paper referenced above.
This cleverly-written tool uses a variety of heuristics to churn through memory, looking for contiguous blocks of RAM that look like the output of the AES key schedule.
This is the algorithm that AES uses at the outset to convert a 128-bit key into 176 bytes of key material to use in the AES process itself, or a 256-bit key into 240 bytes.
And now the burning question. Did the FROSTERs succeed?
Sort-of. They've got some visual material that suggests they did, though whether the key information was actually enough to unscramble the encrypted data on the phone is not specified.
The paper is similarly ambiguous, saying somewhat noncommittally that the authors were "able to recover the disk encryption keys (given that no or only a few bits were decayed)."
That's a bit like saying that "we came out ahead financially every time we placed a winning bet." It doesn't tell us much about the practicability of the attack in real life.
Nevertheless, the FROST paper teaches, nay proves, an important lesson:
If you have an Android phone with an unlockable bootloader, LOCK IT AGAIN WHEN YOU'RE DONE REFLASHING.
The authors are unequivocal about this.
When they needed to unlock the bootloader to try to attack an encrypted phone, they ended up with nothing to decrypt.
Oh, and if you pick up your phone to make a call and it seems unusually cold against your ear, look out!
IBM just released an open source software package called HELib.
Of all the gifts you could leave behind, why a giant wooden horse? Why that shape? Why that size?
The first thing that will attract your attention (perhaps not in the way the marketing people intended) if you are interested in cryptography is its claim to be "the world's first totally secure instant messenger application."
RAM chips don't lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.
If the RAM is at room temperature, its remanence is greatly reduced, so it "forgets" much more quickly.
