Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

iOS 7 Update Silently Removes Encryption For Email Attachments

timothy posted about 3 months ago | from the giveth-and-taketh-away dept.

Bug 68

An anonymous reader writes "Apple has removed encrypted email attachments from iOS 7. Apple said back in June 2010 in regards to iOS 4.0: 'Data protection is available for devices that offer hardware encryption, including iPhone 3GS and later, all iPad models, and iPod touch (3rd generation and later). Data protection enhances the built-in hardware encryption by protecting the hardware encryption keys with your passcode. This provides an additional layer of protection for your email messages attachments, and third-party applications.' Not anymore."

cancel ×

68 comments

Sorry! There are no comments related to the filter you selected.

Or... (0, Interesting)

Anonymous Coward | about 3 months ago | (#46904155)

It's a bug. You know, they have been fixing a number of encryption related things lately. It's entirely possible this is a side effect.

Re:Or... (4, Insightful)

epyT-R (613989) | about 4 months ago | (#46905237)

When it comes to encryption, a paranoid default assumption rules the day.

Re:Or... (2)

hebertrich (472331) | about 4 months ago | (#46906877)

Yup, less trouble for the NSA .. Apple has collected it's 30 silver pieces .

Old. Needs an update. (3, Informative)

Anonymous Coward | about 3 months ago | (#46904159)

This 'news' is about a week or two old. Apple already issued a statement acknowledging the situation and is looking into it.
Will probably fixed with an update.

Re:Old. Needs an update. (0)

Anonymous Coward | about 4 months ago | (#46904759)

This 'news' is about a week or two old. Apple already issued a statement acknowledging the situation and is looking into it. Will probably fixed with an update.

citation needed.

Re:Old. Needs an update. (0)

Anonymous Coward | about 4 months ago | (#46906969)

This 'news' is about a week or two old. Apple already issued a statement acknowledging the situation and is looking into it.
Will probably fixed with an update.

Re:Old. Needs an update. (1)

Rosyna (80334) | about 4 months ago | (#46905109)

What does the author of TFA want? Double-encryption of message attachments? The storage of the iPhone is always encrypted. In order to access any files, you must supply the encryption key. He supplied the key and could read the files.

Unless he wants attachments double encrypted or encrypted on iCloud itself?

Re:Old. Needs an update. (3, Informative)

Anubis IV (1279820) | about 4 months ago | (#46905409)

The storage of the iPhone is always encrypted. In order to access any files, you must supply the encryption key. He supplied the key and could read the files.

From what I understand, that's actually not what's happening here, and that's the problem. He was able to simply mount the disk and gain access to the files, without having to supply an encryption key. In contrast, the messages themselves were encrypted, just as you'd expect. More or less, it turns out that not everything that's stored on the iPhone is actually being encrypted.

Re:Old. Needs an update. (1)

Rosyna (80334) | about 4 months ago | (#46905865)

You cannot mount the disk without the encryption key.

Re:Old. Needs an update. (0)

Anonymous Coward | about 4 months ago | (#46906631)

The disk provides the encryption key (a large string of random bits), what it doesn't provide is the passphrase which was used to mask that key, which would be wrapped with an algorithm like PBKDF2.

The reason to do it this way is, if you change your passphrase you don't want a screen saying "Sorry, re-encrypting the entire drive. Please wait 4 hours". So you store the encryption key, but masked with a bit string derived from your passphrase. Then if the passphrase changes, you just update the masked key, and the actual encryption used remains the same. Clever right? This is how all serious disk encryption works on every platform.

Now if the passphrase is five random English words. That's an incredible number of possibilities, you'll get old waiting to brute force PBKDF2

But if the passphrase is 4 digits, as it is on almost every single iPhone, that's just 10 000 guesses. Trying PBKDF2 for all 4 digit PINs takes a few seconds.

You might object - surely the iPhone will lock after a few guesses? Sure. But we aren't using the iPhone to guess, we are directly accessing the drive and making our own guesses. We can make many guesses per second this way and nothing can slow us down or lock us out. The only way to beat this is to set a longer passphrase.

When you see iPhone users entering long well-chosen passphrases to unlock their phones you'll know they actually have cryptographically protected storage. So long as it's four digits and they're in, they have no meaningful protection and are just lulled into a false sense of security.

Re:Old. Needs an update. (0)

Anonymous Coward | about 4 months ago | (#46906805)

Which is why people requiring security want to get the iphone with touch id: you set a long password which you inconveniently type once, and from there on you use the fingerprint to access immediately.

Yes, short pins are crap for any kind of security. Who would have guessed. Or do you use a 4 digit pin for your server root accounts?

Re:Old. Needs an update. (1)

Munchr (786041) | about 4 months ago | (#46908899)

But even that is doing it wrong. Your fingerprint is NOT a password, it's a login ID. It should only ever be used to identify an account name, rather than be used to protect said account. Using a fingerprint as a password is why it is so trivial to bypass, and gain access to these improperly secured devices.

Re:Old. Needs an update. (1)

michelcolman (1208008) | about 4 months ago | (#46909369)

OK, so if I understood correctly, the entire "disk" (SSD) is encrypted with a key that can be unscrambled with the passphrase (just 4 digits for most people), and Apple used to also encrypt e-mail attachments one extra time on top of the full disk encryption, but now no longer does.

Can anyone explain what the added value was of the extra encryption they used to add and that is apparently so sorely missed now?

After all, what were they using to encrypt those attachments? Errr... the same passphrase, right? After all, I can boot up my iPhone, enter my passphrase, and read all my mail. No other extra strong authentication needed to get to e-mail attachments. If someone can get the password by brute-forcing the full disk encryption, they can then use that password to simply log in and open Mail.

Ergo, the extra encryption was totally useless and just a waste of battery power. Or am I missing something here?

Re: Old. Needs an update. (1)

ikejam (821818) | about 4 months ago | (#46911433)

For one, a it enables a fairly simple and quick Remote wipe: delete the encryption key and remote wipe is done in a second.

Re: Old. Needs an update. (1)

michelcolman (1208008) | about 4 months ago | (#46911601)

Yes, but I was talking about the EXTRA encryption they used to apply to e-mail attachments. The full disk encryption is still present, that hasn't changed. I was just wondering why they bothered to apply an extra encryption step to e-mail attachments if by breaking full disk encryption you could get the passcode and break all the other encryption too without extra effort.

Double? (0)

Anonymous Coward | about 4 months ago | (#46906401)

So you send your whole encrypted storage as an attachment? How does your buddy decrypt that?

Gosh, I always suspected Apple fanbois were a bit incompetent, but *this* is downright scary.

Re: Double? (1)

allan marcus (3380849) | about 4 months ago | (#46907575)

This is simply confusion. Everything on the device is encrypted. Attachment that I sent via email may not be being sent encrypted. That's where the confusion lies.

Title is Misleading (5, Informative)

Anonymous Coward | about 3 months ago | (#46904165)

The encryption for email attachment was not removed, it was never present.

It's not nefarious, it's incompetent.

Read the original (shorter!) post (http://www.andreas-kurtz.de/2014/04/what-apple-missed-to-fix-in-ios-711.html) instead of the rehashed ad-selling copy.

Sponsored by your friendly neighbor, the NSA (-1)

Anonymous Coward | about 3 months ago | (#46904181)

iCrippled.

Tey walled you in... (0)

Anonymous Coward | about 3 months ago | (#46904185)

and got you cornered.

Re: Tey walled you in... (0)

Anonymous Coward | about 4 months ago | (#46906215)

Who is Tey? Its not Tey Robinson is it?

iOS 7 Update Silently Removes Encryption For Email (0)

Anonymous Coward | about 3 months ago | (#46904205)

Probably was proving inconvenient for the NSA.

NSA (0)

Anonymous Coward | about 4 months ago | (#46906449)

So they let you use hardware encryption, but not software (presumably the software version would allowuser programemed methods).

Makes one wonder about back doors in hardware encryption if they let you use that, but not software.

I need more info (2, Insightful)

sgt scrub (869860) | about 3 months ago | (#46904235)

At first glance it looked like there might have been a significant enough performance hit using hardware encryption the took it out. It didn't seem like a big deal. TFA makes it sound like encrypted email I pull from my email server is stored decrypted. That would be a big deal.

Re:I need more info (1)

Anonymous Coward | about 3 months ago | (#46904273)

The idea behind hardware encryption is that there is no performance hit. Software encryption though is a performance hit.

Re:I need more info (0)

Anonymous Coward | about 4 months ago | (#46905351)

When are we going to stop buying in to this "oooo, there's a performance hit!" nonsense? Is that really a blocking reason? Or just an excuse?

If there is anything that recent revelations have made clear, it's that the Three Letter Agencies will hoover up anything they can get their hands on. We also know, from decades of experience, that security must be both easy and the default option. Otherwise many (most?) people will fail to do the right thing, security-wise.

Modern processors have plenty of capacity to handle the encryption overhead. And, if it's really a problem, this item is highly amenable to coprocessing. Extremely high volume servers where this is truly an issue, have both the personnel and budget to handle this matter appropriately, meaning that encryption will happen in spite of the workload. To do otherwise is becoming tantamount to professional incompetence and/or willful neglect. None of which the average sysadmin wants on their resumé.

Do you want to brag about this in your next job search? "1997 - 2014, Mail Server Administrator. Accomplishments: Responsible for a huge security breach caused by mass mail interceptions enabled by unencrypted mail format. Justification? We couldn't spend an extra grand (or less) on a coprocessing NIC. I blame my ex-manager. My ex-manager disagrees." See how that reads? The blame could just as easily fall on you as the manager. A new hiring organization probably won't take the chance and will bypass you.

Quit using the workload of encryption as an excuse to do nothing. That ain't gonna cut it anymore.

Re:I need more info (1)

blackest_k (761565) | about 4 months ago | (#46906541)

As a parallel case encrypted satellite signals were routinely decrypted with software cams for years without problems other than key updates. Nagra 3 still appears to be secure after around 4 or 5 years since its introduction. In comparison to these satellite boxes an iphone is a super computer. OTR used with pidgin encrypts and decrypts as you type.

Just because it is hard to decrypt an encoded block by brute force does not mean it is hard to encrypt and decrypt with a given key set.

Re:I need more info (1)

sgt scrub (869860) | about 4 months ago | (#46905847)

Not in CPU cycles but power. Granted, I should have pointed that out. This is /. after all.

Just a documentation update! (0)

Anonymous Coward | about 3 months ago | (#46904261)

Marketing got ahead of NSA.

No problem (1)

mysidia (191772) | about 3 months ago | (#46904277)

Encrypt your attachment with PGP before sending.

Or use a word .DOC managed by Active Directory Rights Management Services, or else: encrypted with the 'require a password to open this document' option

Re:No problem (0)

Anonymous Coward | about 3 months ago | (#46904391)

Can you do this on an iPhone locally/natively?

Re:No problem (1)

CaptainJeff (731782) | about 3 months ago | (#46904395)

Yep...no problem doing these things ON AN IOS DEVICE...

Re:No problem (0)

Anonymous Coward | about 4 months ago | (#46906069)

So get a better phone then.

Re:No problem (3, Interesting)

jonyen (2633919) | about 3 months ago | (#46904455)

There's an app for that: http://ipgmail.com/ [ipgmail.com]

Re:No problem (2)

Dr. Evil (3501) | about 4 months ago | (#46904561)

None of that helps when you receive an attachment on your device.

Re:No problem (1)

tepples (727027) | about 4 months ago | (#46905041)

Doesn't one of the paid alternative mail user agents support PGP encryption and decryption?

Re:No problem (0)

Anonymous Coward | about 4 months ago | (#46905535)

Is that kind of thing allowed on an iPhone?

I used the Google: ios pgp mail client (1)

tepples (727027) | about 4 months ago | (#46907595)

Apparently so. Google Search queries ios mail clients and ios pgp mail client gave relevant results when I tried them today, one of them being "iPGMail" ($1.99) on the App Store. My only explanation for this is that Apple has loosened up on the whole "duplicating included apps" bit since it first introduced the App Store.

Re:I used the Google: ios pgp mail client (0)

Anonymous Coward | about 4 months ago | (#46908147)

Yeah, FIVE YEARS AGO you fucking dumbass.

Again a clueless article... (4, Informative)

gnasher719 (869701) | about 4 months ago | (#46904829)

Fact is, you can't read the data on a locked iPhone. You _can_ read the data if you, as the owner, unlock the iPhone, for example for backing it up. But if the NSA gets your locked phone into their hands, there's nothing that they can do. All the data is _always_ read and written using hardware decryption.

In addition, apps can use further encryption on a per-file basis. Mail does that for most files, but apparently not for attachments. Additional encryption means for example that entering the key code is needed again for that kind of file. But files without that additional encryption still can't be read.

What the guy is complaining about is like sending unencrypted data over https, or putting unprotected documents into an unbreakable safe.

Re:Again a clueless article... (1)

antdude (79039) | about 4 months ago | (#46905095)

Doesn't Apple have access to these locked phones for law enforcement to request with warrants?

Re:Again a clueless article... (3, Informative)

Anonymous Coward | about 4 months ago | (#46905217)

Do a little googling... It seems Apple bypasses the OS to read the encrypted data directly, then does a brute-force attack on the passcode. Most people use a 4 digit numerical passcode, and very very few use more than 8 alphanumeric digits so brute forcing is usually a matter of minutes. There are third-party forensics tools that can do the same, but most police departments aren't up to speed and have an easier time just shipping the device+warrant to Apple and waiting a few weeks. Your data is only as safe as the password you lock it with...

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46906595)

Yup. We take a guy's phone (pickpocket can do it pretty easily), dump it in the cradle, machine reboots it and cycles through the 10 000 passcodes, typically takes about 5 seconds for that part, then we can do whatever we like to the phone, install spyware, copy files, whatever, and then lock it back up and slip it back in his pocket.

Here's a fun thing to watch, both Apple and Google have thousands of employees using their mobile device platform. Watch a Google engineer unlocking their Android phone. Tap-tap-tap tap-tap-tap tap-tap-tap - what is she doing? Oh she's entering a long pass phrase! Why is she doing that? Because without one the phone's "encrypted" data might as well not be encrypted at all. Now her Apple colleague, one swift movement, 4 digit PIN entered, look how stylish that phone is - and it has top security too, right? Well, I mean, so long as you can't guess those 4 digits in 10 000 tries... oh.

Android's disk encryption is just Linux disk encryption, like on your desktop PC, except integrated into the shiny Android UI. If you use it with a 4 digit PIN, you have essentially no security (maybe it can stop your kid brother writing crap on your Facebook, that's about it). But if you're willing to type a long passphrase (or if corporate security require you to do so and will take the phone away if you don't) then you get the protection of serious encryption.

Re:Again a clueless article... (1)

Bert64 (520050) | about 4 months ago | (#46906663)

You can configure android to use a 4 digit pin (or nothing at all), and you can also configure ios to use a long passphrase (which for most people is just a complete nuisance to enter on a touchscreen device).

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46908459)

Google corporate policy requires a long passphrase. It's not optional. All Google-authorised corporate phones enforce their rules. If you've got a personal phone instead, you can use whatever policy you like, but you can't access most work systems.

Android won't let you have "nothing at all" if you use drive encryption, because it's futile.

Re:Again a clueless article... (1)

Geeky (90998) | about 4 months ago | (#46908619)

Exactly, it's a nuisance. On my phone even a 4 digit pin is a pain - I just want to swipe and start using it. I do put up with a pin to prevent casual nosiness if I leave it on my desk, but otherwise I wouldn't bother.

I care about security, but I also care about the balance between that and convenience. It's risk management - the likelihood of losing my phone is low, the stuff on there isn't that sensitive, so I opt mostly for convenience.

Re: Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46906683)

Where can I find an article about how exactly does apple decrypt a device for law-enforcemnt?

Re:Again a clueless article... (1)

gnasher719 (869701) | about 4 months ago | (#46907691)

Do a little googling... It seems Apple bypasses the OS to read the encrypted data directly, then does a brute-force attack on the passcode. Most people use a 4 digit numerical passcode, and very very few use more than 8 alphanumeric digits so brute forcing is usually a matter of minutes. There are third-party forensics tools that can do the same,

The trick is that only software signed by Apple is able to try out passcodes. When you enter a passcode say 1234, that passcode gets sent to Apple-signed software which then tries it out. Apple can obviously create Apple-signed software that tries any number of keys.

There are two obstacles for this: One, Apple needs a legal search warrant and the actual device. Two, passcode checking is designed to take about 1/10th of a second per key. So 4 digits can be cracked in 15 minutes. 8 digits would take months. 8 digits and letters are uncrackable.
br Third-party forensic tools can't do that unless they can jailbreak your phone, so update the OS to a version that cannot be jailbroken. Third-party tools tend to attack backups, but you can tell iTunes to make encrypted backups. (That also has the advantage that iTunes will backup passwords stored on the phone; it doesn't back them up to an unencrypted backup).

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46908503)

No need to jailbreak the phone. No need to wait for the iPhone to check the passcode. The drive is right there inside the phone, you can try passcodes as quickly as you can calculate PBKDF2 and compare to the data on the drive.

In theory eight digits would take a few hours this way. But in practice nobody even bothers to offer the option. If you confiscate and analyse a thousand iPhones every year, you'll still go years without seeing one that has a better than 4 digit PIN.

Re:Again a clueless article... (0)

BitZtream (692029) | about 4 months ago | (#46905231)

No

Re:Again a clueless article... (2)

DigiShaman (671371) | about 4 months ago | (#46905097)

Doesn't the master code get stored on Apple's iCloud network for iOS devices? I know it's optional to have it backed up there when using FileVault for OSX. Anyways, all the NSA has to do is subpoena the information from Apple and they're in like Flynn!

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46905177)

No, iCloud does not have a copy of your ios device's encryption key or passcode.

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46905683)

No, iCloud does not have a copy of your ios device's encryption key or passcode.

We can totally trust what several colluding organizations and governments say on the books, the more so after they were caught in the act a few times.

Re:Again a clueless article... (1)

SuperKendall (25149) | about 4 months ago | (#46905793)

No, we can trust the MANY hackers who have checked and found the master key is not transmitted.

Re:Again a clueless article... (1)

gnasher719 (869701) | about 4 months ago | (#46907731)

Doesn't the master code get stored on Apple's iCloud network for iOS devices? I know it's optional to have it backed up there when using FileVault for OSX. Anyways, all the NSA has to do is subpoena the information from Apple and they're in like Flynn!

Doesn't get stored anywhere. FileVault for MacOS X works slightly different because it has no individual key built into the CPU. When you backup that key with Apple, you have to supply three security questions + answers and it looks like the answers are not stored but just used to encrypt / decrypt the key. Apple states that without the security answers, they are not capable of supplying the code.

Re:Again a clueless article... (1)

AmiMoJo (196126) | about 4 months ago | (#46906597)

Do you trust Apple's hardware encryption implementation? If I wanted a secure phone I'd want one where the encryption system was open source so I could verify it myself. After Goto Fail and Heartbleed people are looking at this stuff a lot more closely, when possible.

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46906639)

>But if the NSA gets your locked phone into their hands, there's nothing that they can do.

Hahahahahahahaha.

Re:Again a clueless article... (0)

Anonymous Coward | about 4 months ago | (#46909537)

But if the NSA gets your locked phone into their hands, there's nothing that they can do.

Riiight. If you actually believe that apple won't unlock the iphone for them, you're an idiot.

Apple has been well-documented in unlocking iphones for law enforcement. Given that, why would apple not unlock an iphone for the NSA?

Of course, it's also highly likely that the iphone has significant encryption flaws and the NSA doesn't need to bother apple at all.

Crapple (0)

koan (80826) | about 4 months ago | (#46905213)

NSA compliance continues.

WSA - Is this S/MIME? (0)

Anonymous Coward | about 4 months ago | (#46905671)

WSA = what a shit article?

have they removed S/MIME or wtf is this about?

Silently. SILENTLY! (4, Funny)

konohitowa (220547) | about 4 months ago | (#46906005)

They forgot to use the phrases "much maligned" and "beleaguered". But "silently" is always a great fallback.

BlackBerry FTW (1)

acoustix (123925) | about 4 months ago | (#46906011)

Suck it, iOS fanbois.

Re:BlackBerry FTW (1)

Wovel (964431) | about 4 months ago | (#46906061)

Ah blackberry where they don't need your device because they just hand over the keys to the completely unnecessary server companies were forced to stick in the middle of the email chain.

Re:BlackBerry FTW (1)

narcc (412956) | about 4 months ago | (#46907719)

Ah, you're confused, I see. They can't "hand over the keys" because they don't have them. As always, BES users are safe.

Or are you that guy who keeps repeating this despite being told, multiple times, that it's nonsense?

WOW, how are they doing this? (0)

Anonymous Coward | about 4 months ago | (#46906637)

Have they found some way to crack all encryption schemes in almost 0 time?
Oh wait, no, it's just a sensationalist headline.

Meh (1)

excelsior_gr (969383) | about 4 months ago | (#46906835)

What kind of idiot has sensitive data on their iStuff (or Android, for that matter), anyway? Companies go with Blackberry for this exact reason.

Re:Meh (1)

dinfinity (2300094) | about 4 months ago | (#46907153)

Almost everybody.

Sensitive corporate data is not the same as sensitive data in general.

Big deal? (1)

countach (534280) | about 4 months ago | (#46906837)

I have to say I don't see the big deal. If you're going to encrypt email attachments, what about the emails? What about all your other data? That's what disk encryption is for surely. This was just a band aid for one scenario among hundreds.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>