Security questions only get you into your iCloud login. They can’t remote unlock your phone. They can remote WIPE it, which is concerning, but it’s unlikely to help the cops gather evidence against you.
It does look like there are reset venues that would allow iCloud to restore data back to your phone after you force wipe it without the passcode (see http://support.apple.com/kb/HT...). That doesn’t appear to be the case if you backup locally to iTunes and enable encryption on that backup.
Today’s lesson: Cloud backup is generally a security risk.
I look forward to Apple stepping up and enabling client-side encryption of iCloud backups like Crashplan & Co. do with your data.
You are correct, sir. That’s exactly what the crypto chip on iDevices does.
There’s no way to direct dump encrypted flash, so you’d need to desolder the flash chips, then you’re busting 2^128 keys for the raw AES key, not just looking for my luggage combination...
It’ll take you longer than 60 seconds. You get six tries for free. Between 6 & 7, you have to wait a minute. Between 7 & 8, it’s five minutes. I think it goes up to an hour before the 10th that wipes it is accepted.
(I just verified up to the five minute wait on my iPad. Six minutes total research is more than enough for a/. article, never mind a comment...)
Case law is slightly conflicted in different US Federal districts, but the majority are that you can’t be compelled to provide your decryption keys. They’d need evidence to throw you in prison for 30 years, and your lack of providing the key is NOT evidence.
Recent statements made by several SCOTUS justices relating to warrantless phone searches suggest that as cases involving compelled key disclosure reach the Supreme Court, they will likely be decided in favor of the defendant. IE that the 5th Amendment protects you from being compelled to turn over an encryption key to information that would be used against you.
The legal situation outside the US is of course different. In the UK in particular, you CAN be compelled to provide the key under penalty of indefinite detention.
Loading the CPU with custom software would either require a ROM-level vulnerability in the bootloader or for Apple to sign your alternate firmware to load in.
To my knowledge there have been no bootloader vulns since the early production runs of the iPhone 4S. All jailbreaks since that time have depended on vulnerabilities later in the software stack. The bootloader will not accept a firmware older than the one currently installed on it, so downgrading to exploit since-fixed bugs isn’t possible.
There’s no existing precedent that I know of, but conceivably Apple could be compelled to sign your mal-firmware. Then you’re down to the bigger problem. The bootloader only maintains the user flash session key in the cryptochip during upgrades if the user’s key is available. If you don’t have the key, installing any firmware blows away the cryptochip’s contents, destroying any ability to access the user flash contents. So the ROM-based bootloader won’t allow you to update the OS to install your alternative version without either clearing user flash or having the user’s key in the first place.
The software that’s on device does implement brute force attacks and (if so-configured) blows away keys in the cryptochip after 10 bad guesses (with an increasing back-off delay before accepting additional guesses after the first six, making it time consuming for someone to DoS your phone by guessing keys until it wipes).
So it’s not possible to load software that ignores the brute force check without wiping what you’re trying to extract in the first place, even with Apple’s (compelled) assistance.
For the AES encryption used on the iOS flash, you need advances in the discrete logarithm problem, not factoring large numbers. There’s no RSA involved in protecting the flash contents.
Additionally, there’s no known way to make the boot loader just dump an image of the encrypted flash for you to start brute forcing on. You’d need to disassemble the phone, desolder the flash chips, and read them out in another circuit.
That’s certainly do-able, but not something that can be done to a phone that needs to continue to remain intact for any reason. IE they couldn’t just dump your phone while you’re in the tank & give it back to you when you’re released, planning to work on it later.
One of those 100+ lbs overweight(*) people buying diet soda would be me. Around the beginning of 2012, I was 200+ lbs more overweight than I am now. I’ve been drinking on average two liters of that diet soda pretty much every day since then and yet managed to shed a significant percentage of my body weight.
I’d say that for most of those “severely disabled” folks you’re complaining about, the other contents of their shopping carts (lots of sugars and starches, especially in “diet” foods), and probably even more so the food not in their shopping carts — IE restaurants / fast food / etc — are far more likely to be the source of the extra weight they’re carrying around.
As far as severely disabled goes, I run 5k’s for fun, a woman I know who’s also 100+ lbs over her “ideal” weight runs marathons for fun along side her (also technically overweight) father who’s in his late 50’s.
But please, do continue to spout off about how diet soda makes you fat with no reasonable (IE sufficient sample size, double blind, etc.) studies to back up your assertion.
That said, I’ll give you the neurological function bit. I definitely get sugar-stupid when I have too much starch/sugar, but non-sugar soda has exactly nothing to do with that.
(*) Assuming you accept BMI as a reasonable measure of ideal body weight. Personally I have some issues with it, and I’d consider myself more like 70-80lbs overweight based on what I consider to be a healthy weight. I’ve reached the conclusion of what I consider to be healthy by observing people of approximately my height and general musculature and their weight. BMI charts say I should be 20-30 lbs lighter than the absolute bottom of what I consider to look “healthy.”
Blame that on ‘murka if you like, but I think 140lbs on a 6’ reasonably muscular male (that’s the bottom end of “normal” according to BMI charts) would look emaciated, not healthy.
One of the world’s greater mysteries, as far as I’m concerned. Also, what’s up with caffeine-free diet Mountain Dew? Might as well just drink antifreeze. The color’s right, and it probably tastes better...
You’d be surprised how low-cal turds are... Mostly indigestible (at least to us) fiber, metabolic wastes, and deceased intestinal fauna.
The human body is shockingly good at absorbing every possible calorie it can from food. I’ve seen 90% efficiency thrown around online, but alas I can’t find any sources worth citing.
Your body absorbs and uses what it has until it has what it needs, and it converts the rest to glycogen and/or fat to use when it needs it later. Problem is “later” never comes when you have a constant supply of food and eat more than your immediate needs on a regular basis.
Your stated relationship is true, but there are indeed other factors involved. The ‘kcal out’ term is influenced by the makeup of the ‘kcal in’ term, so it’s not quite that simple. Your BMR will change based on what you eat, not just how much you eat.
Keep carb intake low enough to stay in ketosis, and your BMR increases 700-ish kcal/day. Drop protein intake too low, and your body starts shutting down non-essential processes to conserve protein & energy causing BMR to decrease.
Both of those effects can result in the inequality between ‘kcal in’ & ‘kcal out' shifting, even as 'kcal in' and activity are constant.
Explain how living across the street from tract housing increases property value versus living across the street from a corn field? It most certainly doesn’t according to my wallet.
I’ll take farm land over McMansions any day, thanks.
This is essentially what Lavabit implemented. The NSA’s response was to compel Lavabit to hand over their SSL private keys so that all traffic to & from their web server could be intercepted. The key material that protects the private key must at some point pass over the wire, and if you can decrypt all traffic in & out, you can compromise the system.
Lavabit chose to go out of business rather than comply.
You’re thinking Web of Trust type public key architecture like PGP/GPG tend to use. That’s a good model among people who know each other well and trust each other (as well as trust each other’s ability to verify keys properly), but it doesn’t scale all that well. It also requires users to do much more work to distribute and verify keys.
iMessage uses a certificate authority model. You delegate all trust to the third party authority (Apple in this case) who you trust to do the work of verifying that keys belong to whom they claim to. Instead of restricting your keys to a list of trusted friends you’ve manually verified, you trust that any key which Apple has signed and provided to you (and hasn’t revoked) was originally provided to Apple by someone who had the user’s iCloud password. It’s a big step up in terms of usability since you don’t need to do the key exchange dance with every person you want to iMessage, but there are significant trade-offs in terms of security.
On the whole (and LEO meddling notwithstanding), Apple’s system does a reasonable job in its role as a CA. You need a user’s iCloud password to provide new keys to the system. As an unfortunate number of famous people recently discovered, relying on password authentication has some limitations, but it’s the best option widely available right now. In any case, the security is reasonably in the user’s hands (again, ignoring LEO for the moment) — you can choose to use long, complex passwords, and Apple will do the RightThing(tm) with them.
The vulnerability in relying on a certificate authority is that they are much more susceptible to coercion by other parties (IE law enforcement). In a Web of Trust model, someone would need to directly compel someone you trust to either turn over their private keys or furnish you with compromised keys that they claim to be safe to use. That must be done on a per-user basis, so requires much more work for LEO to surveil any large number of users. On the other hand, Web of Trust is more susceptible to non-LEO blackmail scenarios. To coin a movie plot, “Here’s a photo of your daughter’s school. Provide this key to all of your trusted confidantes if you want her to get home safe.”
With a certificate authority system, the CA likely has less skin in the game in terms of the security *your* particular messages, and also has significant legal exposure in terms of assets and criminal sanctions. There’s also no possible claim of 5th Amendment protection. The CA can be compelled to produce vulnerable certificates that will appear to come from the surveillance target. They can (technically) do this for a single user or provide the root signing keys allowing LEO to directly produce such certificates without additional involvement from Apple. They can also be legally gagged to prevent them from disclosing this has happened.
The strength in the iMessage implementation is that each iMessage client should be furnished with a complete list of the recipient’s keys and that Apple can’t decrypt messages with the key material it should normally have. That falls apart when Apple is compelled to generate MitM keys for LEO, but there are technical avenues available for detecting that in most cases (unanticipated key change). Those checks essentially degrade back to a Web of Trust model where users must manually authenticate keys with the owner. Most users aren’t savvy enough to perform these checks, and the iMessage infrastructure on iOS devices makes it impossible to do this in-situ without jailbreaking the device. It should be possible to write something that would impersonate an iMessage client and perform the check, but of course if Apple detected the impersonated client, they could provide a different set of certs to that client, defeating the ability to check them.
All told, iMessage is much better than other options available. By design,
I’m not sure (stationary) magnets are a large concern.
A friend of mine in high school had an on-going sibling... disagreement? with his older brother. At one point, he took to storing a 12” speaker (just the bare speaker, no cabinet) magnetically stuck to the side of his brother’s computer case, right where the hard drive sat spinning all day long. He’d sneak in, remove the magnet before his brother got home, put it back when he was gone. That went on for months with no data loss.
Compare the rated interior temperatures of any fire safe you might buy with the maximum storage temperature of any drives, tape, discs, etc. you might plan to use.
Any decent fire safe will keep your important papers below 451F, but a quick googling of “max hard drive storage temperature” suggests that’s a good 300 degrees above “safe” for drives. I suspect tape will melt or demagnetize a good bit below where paper burns as well.
If you’ve gone to the trouble of making a second offline copy, store it someplace other than your basement. Relative or friend’s house? Locked box in your desk at work? Plenty of safer options
Article subject says, “email,” but TFS says, “iMessages.” Those are different things, and the security of them is handled very differently because the mechanism of access is very different.
Apple being unable to access emails is impossible since they must deliver them in plain text to plain-old IMAP clients that don’t support decryption or key storage.
Apple being unable to access iMessage contents is plausible. My understanding of the protocol is something like this:
Alice starts texting Bob’s phone number. Alice’s iDevice contacts Apple’s servers to see if Bob’s phone number is registered with iMessage. If not, Alice’s device sends a plain-old SMS. If it is, Alice’s device receives a list of public keys for each of Bob’s registered iDevices. Alice’s iDevice encrypts the message with a session key, then encrypts that session key to each of Bob’s public keys. Her device transmits the encrypted message to Apple’s servers which then transmit it to each of Bob’s devices as they become accessible. Each of Bob’s registered devices can use its private key to decrypt one of the encrypted session key blocks, then use that to decrypt the message.
The private key to decrypt session keys never leaves Bob’s device. The session key never travels in the clear outside Alice’s or Bob’s devices. Apple can retrieve sender/recipient info (ye olde metadata), but no message contents.
The one gotcha to all of that is that since Apple controls all SSL certs involved in the process, they could MitM attack the process if they so-choose (or were so-ordered). There’s no certificate pinning or checking implemented, so Alice’s iDevice has no way of knowing if the public keys it retrieved for Bob’s iDevices might also include an extra key held by Apple or LEO.
Assuming Apple is compelled to intercept messages from Alice starting at a particular date, messages sent before that date at rest on their server should remain secure (unless they’re lying and are currently MitM or escrowing keys). New messages sent while the MitM was active could be decrypted and provided to LEO. Whether or not they’re performing an MitM at present should be detectable by analyzing the traffic during new device registration or sending messages — IE if Alice checks the keys received and confirms them all with Bob manually (jailbreak most likely required). If they don’t match or there’s an extra key, something’s wrong.
Scroll to the bottom for the tl;dr on that analysis. That post also includes proof of concept software to check for an active MitM attack, at least on iMessage for Mac.
tl;dr: Apple is in a trusted position where they could intercept message on a per-user basis if compelled to do so, but the general case of iMessage working as intended leaves messages encrypted on their server with keys they don’t have. I’m not aware of any way that Apple could perform that attack in an undetectable fashion, though performing that detection is well beyond the ability of most users.
For cloud-based storage I care about viability. If they go out of business and take my one cloudy copy with then, I’m screwed.
For cloud-based backup, that’s a different story. If they go out of business, I only care if it happens to occur in the timeframe that my own local copy is damaged. It’s certainly in the realm of possibility that would happen, but I’m okay with those odds given the price Backblaze, Crashplan, and others are currently charging. If it should happen that they go bust, I’ll have to find another solution. In the mean time, it’s reasonably priced insurance, especially when compared to the cost of backing up to tape, buying (and admin’ing) an off-site server, etc.
If they’re profitable or not is between them and their investors. Having read how Backblaze goes about sourcing disks and constructing their storage pods, I’d definitely say they have profitability in mind. I hope they make a good run of it, but if not, there’s a decent chance that my local storage will be and remain intact long enough to find another solution, be it one of their competitors, a bunch of local disks, or, “Hey Mom? Do you mind if I stick this loud, hot, power guzzling thing in your basement?”
Perfect forever backups would be nice, but I haven’t got that kind of IT budget at home. Compromises will have to be made, and I think the cloud-based options are a pretty good bargain right now.
Inability to import after a damaged/missing ZIL is an old problem of ZoL (and ZFS in general) that’s (long) since been fixed. ZFS on-disk version 19 and newer support removal of a faulted / missing secondary log device. ZFSv19 was released in OpenSolaris b125 (sometime in 2009 - can’t pin down an exact date). I can’t find an easy reference of ZoL versions versus their supported ZFS versions, but the earliest release on the zfsonlinux.org home page (0.6.1 released 27-MAR-2013) supports SLOG removal.
It takes some debugging steps, but it’s doable without loss of a pool where missing ZIL was the only problem. Additional problems may of course prevent import, but if the ZIL is your only issue, it’s recoverable with current ZoL. Likewise for missing L2ARC devices.
As you mentioned you run the risk of losing data that was “guaranteed” written but only in the ZIL at the time the system lost power or crashed. If the pool was exported cleanly, there would be no uncommitted data in the ZIL, so this would only be a possibility after power loss or system crash.
ZFS on BSD, then Linux (same hardware, new OS) since about 2008. 19TB raw, about 14TB w/ RAID taken into account. Not using ECC since day one.
Nothing catastrophic has happened, and any issues with repairs made during ZFS scrubs have eventually proven to be failing drives, flaky cables, or cheap/lousy SATA backplanes. IE replacement of offending hardware caused rare intermittent CRC errors to cease completely (until the next non-RAM thing started acting up). Even with those errors, zero dataloss over the time frame.
ECC’s a nice feap, but your data won’t catch fire without it.
This is exactly what I see: much bigger hit on I/O than CPU for scrub.
I use maybe 30% CPU on a slow old quad Core2 vintage CPU while scrubbing about 14TB on three pools (all three pools running concurrently). I/O is flattened while it’s running, but CPU isn’t that bad all things considered.
No, but being easier for barely capable techs to cobble something together that “works” in less time is considered an upgrade.
Remember: IT security is a separate cost of doing business. Cutting IT security costs improves the bottom line. Increasing costs for “only” security has no business benefit.
Slashdot Mirror
Security questions only get you into your iCloud login. They can’t remote unlock your phone. They can remote WIPE it, which is concerning, but it’s unlikely to help the cops gather evidence against you.
It does look like there are reset venues that would allow iCloud to restore data back to your phone after you force wipe it without the passcode (see http://support.apple.com/kb/HT...). That doesn’t appear to be the case if you backup locally to iTunes and enable encryption on that backup.
Today’s lesson: Cloud backup is generally a security risk.
I look forward to Apple stepping up and enabling client-side encryption of iCloud backups like Crashplan & Co. do with your data.
You are correct, sir. That’s exactly what the crypto chip on iDevices does.
There’s no way to direct dump encrypted flash, so you’d need to desolder the flash chips, then you’re busting 2^128 keys for the raw AES key, not just looking for my luggage combination...
I *think* iOS 7 on TouchID capable devices also pressed you to use a complex password.
It’ll take you longer than 60 seconds. You get six tries for free. Between 6 & 7, you have to wait a minute. Between 7 & 8, it’s five minutes. I think it goes up to an hour before the 10th that wipes it is accepted.
(I just verified up to the five minute wait on my iPad. Six minutes total research is more than enough for a /. article, never mind a comment...)
Case law is slightly conflicted in different US Federal districts, but the majority are that you can’t be compelled to provide your decryption keys. They’d need evidence to throw you in prison for 30 years, and your lack of providing the key is NOT evidence.
Recent statements made by several SCOTUS justices relating to warrantless phone searches suggest that as cases involving compelled key disclosure reach the Supreme Court, they will likely be decided in favor of the defendant. IE that the 5th Amendment protects you from being compelled to turn over an encryption key to information that would be used against you.
The legal situation outside the US is of course different. In the UK in particular, you CAN be compelled to provide the key under penalty of indefinite detention.
Loading the CPU with custom software would either require a ROM-level vulnerability in the bootloader or for Apple to sign your alternate firmware to load in.
To my knowledge there have been no bootloader vulns since the early production runs of the iPhone 4S. All jailbreaks since that time have depended on vulnerabilities later in the software stack. The bootloader will not accept a firmware older than the one currently installed on it, so downgrading to exploit since-fixed bugs isn’t possible.
There’s no existing precedent that I know of, but conceivably Apple could be compelled to sign your mal-firmware. Then you’re down to the bigger problem. The bootloader only maintains the user flash session key in the cryptochip during upgrades if the user’s key is available. If you don’t have the key, installing any firmware blows away the cryptochip’s contents, destroying any ability to access the user flash contents. So the ROM-based bootloader won’t allow you to update the OS to install your alternative version without either clearing user flash or having the user’s key in the first place.
The software that’s on device does implement brute force attacks and (if so-configured) blows away keys in the cryptochip after 10 bad guesses (with an increasing back-off delay before accepting additional guesses after the first six, making it time consuming for someone to DoS your phone by guessing keys until it wipes).
So it’s not possible to load software that ignores the brute force check without wiping what you’re trying to extract in the first place, even with Apple’s (compelled) assistance.
For the AES encryption used on the iOS flash, you need advances in the discrete logarithm problem, not factoring large numbers. There’s no RSA involved in protecting the flash contents.
Additionally, there’s no known way to make the boot loader just dump an image of the encrypted flash for you to start brute forcing on. You’d need to disassemble the phone, desolder the flash chips, and read them out in another circuit.
That’s certainly do-able, but not something that can be done to a phone that needs to continue to remain intact for any reason. IE they couldn’t just dump your phone while you’re in the tank & give it back to you when you’re released, planning to work on it later.
One of those 100+ lbs overweight(*) people buying diet soda would be me. Around the beginning of 2012, I was 200+ lbs more overweight than I am now. I’ve been drinking on average two liters of that diet soda pretty much every day since then and yet managed to shed a significant percentage of my body weight.
I’d say that for most of those “severely disabled” folks you’re complaining about, the other contents of their shopping carts (lots of sugars and starches, especially in “diet” foods), and probably even more so the food not in their shopping carts — IE restaurants / fast food / etc — are far more likely to be the source of the extra weight they’re carrying around.
As far as severely disabled goes, I run 5k’s for fun, a woman I know who’s also 100+ lbs over her “ideal” weight runs marathons for fun along side her (also technically overweight) father who’s in his late 50’s.
But please, do continue to spout off about how diet soda makes you fat with no reasonable (IE sufficient sample size, double blind, etc.) studies to back up your assertion.
That said, I’ll give you the neurological function bit. I definitely get sugar-stupid when I have too much starch/sugar, but non-sugar soda has exactly nothing to do with that.
(*) Assuming you accept BMI as a reasonable measure of ideal body weight. Personally I have some issues with it, and I’d consider myself more like 70-80lbs overweight based on what I consider to be a healthy weight. I’ve reached the conclusion of what I consider to be healthy by observing people of approximately my height and general musculature and their weight. BMI charts say I should be 20-30 lbs lighter than the absolute bottom of what I consider to look “healthy.”
Blame that on ‘murka if you like, but I think 140lbs on a 6’ reasonably muscular male (that’s the bottom end of “normal” according to BMI charts) would look emaciated, not healthy.
One of the world’s greater mysteries, as far as I’m concerned. Also, what’s up with caffeine-free diet Mountain Dew? Might as well just drink antifreeze. The color’s right, and it probably tastes better...
You’d be surprised how low-cal turds are... Mostly indigestible (at least to us) fiber, metabolic wastes, and deceased intestinal fauna.
The human body is shockingly good at absorbing every possible calorie it can from food. I’ve seen 90% efficiency thrown around online, but alas I can’t find any sources worth citing.
Your body absorbs and uses what it has until it has what it needs, and it converts the rest to glycogen and/or fat to use when it needs it later. Problem is “later” never comes when you have a constant supply of food and eat more than your immediate needs on a regular basis.
Your stated relationship is true, but there are indeed other factors involved. The ‘kcal out’ term is influenced by the makeup of the ‘kcal in’ term, so it’s not quite that simple. Your BMR will change based on what you eat, not just how much you eat.
Keep carb intake low enough to stay in ketosis, and your BMR increases 700-ish kcal/day. Drop protein intake too low, and your body starts shutting down non-essential processes to conserve protein & energy causing BMR to decrease.
Both of those effects can result in the inequality between ‘kcal in’ & ‘kcal out' shifting, even as 'kcal in' and activity are constant.
Explain how living across the street from tract housing increases property value versus living across the street from a corn field? It most certainly doesn’t according to my wallet.
I’ll take farm land over McMansions any day, thanks.
You just get out of the corner with that goat. And pull yer pants back up, dammit!
This is essentially what Lavabit implemented. The NSA’s response was to compel Lavabit to hand over their SSL private keys so that all traffic to & from their web server could be intercepted. The key material that protects the private key must at some point pass over the wire, and if you can decrypt all traffic in & out, you can compromise the system.
Lavabit chose to go out of business rather than comply.
Land of the Free indeed...
You’re thinking Web of Trust type public key architecture like PGP/GPG tend to use. That’s a good model among people who know each other well and trust each other (as well as trust each other’s ability to verify keys properly), but it doesn’t scale all that well. It also requires users to do much more work to distribute and verify keys.
iMessage uses a certificate authority model. You delegate all trust to the third party authority (Apple in this case) who you trust to do the work of verifying that keys belong to whom they claim to. Instead of restricting your keys to a list of trusted friends you’ve manually verified, you trust that any key which Apple has signed and provided to you (and hasn’t revoked) was originally provided to Apple by someone who had the user’s iCloud password. It’s a big step up in terms of usability since you don’t need to do the key exchange dance with every person you want to iMessage, but there are significant trade-offs in terms of security.
On the whole (and LEO meddling notwithstanding), Apple’s system does a reasonable job in its role as a CA. You need a user’s iCloud password to provide new keys to the system. As an unfortunate number of famous people recently discovered, relying on password authentication has some limitations, but it’s the best option widely available right now. In any case, the security is reasonably in the user’s hands (again, ignoring LEO for the moment) — you can choose to use long, complex passwords, and Apple will do the RightThing(tm) with them.
The vulnerability in relying on a certificate authority is that they are much more susceptible to coercion by other parties (IE law enforcement). In a Web of Trust model, someone would need to directly compel someone you trust to either turn over their private keys or furnish you with compromised keys that they claim to be safe to use. That must be done on a per-user basis, so requires much more work for LEO to surveil any large number of users. On the other hand, Web of Trust is more susceptible to non-LEO blackmail scenarios. To coin a movie plot, “Here’s a photo of your daughter’s school. Provide this key to all of your trusted confidantes if you want her to get home safe.”
With a certificate authority system, the CA likely has less skin in the game in terms of the security *your* particular messages, and also has significant legal exposure in terms of assets and criminal sanctions. There’s also no possible claim of 5th Amendment protection. The CA can be compelled to produce vulnerable certificates that will appear to come from the surveillance target. They can (technically) do this for a single user or provide the root signing keys allowing LEO to directly produce such certificates without additional involvement from Apple. They can also be legally gagged to prevent them from disclosing this has happened.
The strength in the iMessage implementation is that each iMessage client should be furnished with a complete list of the recipient’s keys and that Apple can’t decrypt messages with the key material it should normally have. That falls apart when Apple is compelled to generate MitM keys for LEO, but there are technical avenues available for detecting that in most cases (unanticipated key change). Those checks essentially degrade back to a Web of Trust model where users must manually authenticate keys with the owner. Most users aren’t savvy enough to perform these checks, and the iMessage infrastructure on iOS devices makes it impossible to do this in-situ without jailbreaking the device. It should be possible to write something that would impersonate an iMessage client and perform the check, but of course if Apple detected the impersonated client, they could provide a different set of certs to that client, defeating the ability to check them.
All told, iMessage is much better than other options available. By design,
I’m not sure (stationary) magnets are a large concern.
A friend of mine in high school had an on-going sibling ... disagreement? with his older brother. At one point, he took to storing a 12” speaker (just the bare speaker, no cabinet) magnetically stuck to the side of his brother’s computer case, right where the hard drive sat spinning all day long. He’d sneak in, remove the magnet before his brother got home, put it back when he was gone. That went on for months with no data loss.
Compare the rated interior temperatures of any fire safe you might buy with the maximum storage temperature of any drives, tape, discs, etc. you might plan to use.
Any decent fire safe will keep your important papers below 451F, but a quick googling of “max hard drive storage temperature” suggests that’s a good 300 degrees above “safe” for drives. I suspect tape will melt or demagnetize a good bit below where paper burns as well.
If you’ve gone to the trouble of making a second offline copy, store it someplace other than your basement. Relative or friend’s house? Locked box in your desk at work? Plenty of safer options
But what about my precious copy of the Ewoks Christmas?????
Article subject says, “email,” but TFS says, “iMessages.” Those are different things, and the security of them is handled very differently because the mechanism of access is very different.
Apple being unable to access emails is impossible since they must deliver them in plain text to plain-old IMAP clients that don’t support decryption or key storage.
Apple being unable to access iMessage contents is plausible. My understanding of the protocol is something like this:
Alice starts texting Bob’s phone number. Alice’s iDevice contacts Apple’s servers to see if Bob’s phone number is registered with iMessage. If not, Alice’s device sends a plain-old SMS. If it is, Alice’s device receives a list of public keys for each of Bob’s registered iDevices. Alice’s iDevice encrypts the message with a session key, then encrypts that session key to each of Bob’s public keys. Her device transmits the encrypted message to Apple’s servers which then transmit it to each of Bob’s devices as they become accessible. Each of Bob’s registered devices can use its private key to decrypt one of the encrypted session key blocks, then use that to decrypt the message.
The private key to decrypt session keys never leaves Bob’s device. The session key never travels in the clear outside Alice’s or Bob’s devices. Apple can retrieve sender/recipient info (ye olde metadata), but no message contents.
The one gotcha to all of that is that since Apple controls all SSL certs involved in the process, they could MitM attack the process if they so-choose (or were so-ordered). There’s no certificate pinning or checking implemented, so Alice’s iDevice has no way of knowing if the public keys it retrieved for Bob’s iDevices might also include an extra key held by Apple or LEO.
Assuming Apple is compelled to intercept messages from Alice starting at a particular date, messages sent before that date at rest on their server should remain secure (unless they’re lying and are currently MitM or escrowing keys). New messages sent while the MitM was active could be decrypted and provided to LEO. Whether or not they’re performing an MitM at present should be detectable by analyzing the traffic during new device registration or sending messages — IE if Alice checks the keys received and confirms them all with Bob manually (jailbreak most likely required). If they don’t match or there’s an extra key, something’s wrong.
There’s an in-depth protocol analysis of iMessage here: http://blog.quarkslab.com/imes...
Scroll to the bottom for the tl;dr on that analysis. That post also includes proof of concept software to check for an active MitM attack, at least on iMessage for Mac.
tl;dr: Apple is in a trusted position where they could intercept message on a per-user basis if compelled to do so, but the general case of iMessage working as intended leaves messages encrypted on their server with keys they don’t have. I’m not aware of any way that Apple could perform that attack in an undetectable fashion, though performing that detection is well beyond the ability of most users.
For cloud-based storage I care about viability. If they go out of business and take my one cloudy copy with then, I’m screwed.
For cloud-based backup, that’s a different story. If they go out of business, I only care if it happens to occur in the timeframe that my own local copy is damaged. It’s certainly in the realm of possibility that would happen, but I’m okay with those odds given the price Backblaze, Crashplan, and others are currently charging. If it should happen that they go bust, I’ll have to find another solution. In the mean time, it’s reasonably priced insurance, especially when compared to the cost of backing up to tape, buying (and admin’ing) an off-site server, etc.
If they’re profitable or not is between them and their investors. Having read how Backblaze goes about sourcing disks and constructing their storage pods, I’d definitely say they have profitability in mind. I hope they make a good run of it, but if not, there’s a decent chance that my local storage will be and remain intact long enough to find another solution, be it one of their competitors, a bunch of local disks, or, “Hey Mom? Do you mind if I stick this loud, hot, power guzzling thing in your basement?”
Perfect forever backups would be nice, but I haven’t got that kind of IT budget at home. Compromises will have to be made, and I think the cloud-based options are a pretty good bargain right now.
ZFS on Gentoo does not automatically update pool or filesystem versions after a ZFS driver update.
I suspect this is also true of the vast majority of distros, but there’s one example for you anyway.
Inability to import after a damaged/missing ZIL is an old problem of ZoL (and ZFS in general) that’s (long) since been fixed. ZFS on-disk version 19 and newer support removal of a faulted / missing secondary log device. ZFSv19 was released in OpenSolaris b125 (sometime in 2009 - can’t pin down an exact date). I can’t find an easy reference of ZoL versions versus their supported ZFS versions, but the earliest release on the zfsonlinux.org home page (0.6.1 released 27-MAR-2013) supports SLOG removal.
It takes some debugging steps, but it’s doable without loss of a pool where missing ZIL was the only problem. Additional problems may of course prevent import, but if the ZIL is your only issue, it’s recoverable with current ZoL. Likewise for missing L2ARC devices.
As you mentioned you run the risk of losing data that was “guaranteed” written but only in the ZIL at the time the system lost power or crashed. If the pool was exported cleanly, there would be no uncommitted data in the ZIL, so this would only be a possibility after power loss or system crash.
ZFS on BSD, then Linux (same hardware, new OS) since about 2008. 19TB raw, about 14TB w/ RAID taken into account. Not using ECC since day one.
Nothing catastrophic has happened, and any issues with repairs made during ZFS scrubs have eventually proven to be failing drives, flaky cables, or cheap/lousy SATA backplanes. IE replacement of offending hardware caused rare intermittent CRC errors to cease completely (until the next non-RAM thing started acting up). Even with those errors, zero dataloss over the time frame.
ECC’s a nice feap, but your data won’t catch fire without it.
This is exactly what I see: much bigger hit on I/O than CPU for scrub.
I use maybe 30% CPU on a slow old quad Core2 vintage CPU while scrubbing about 14TB on three pools (all three pools running concurrently). I/O is flattened while it’s running, but CPU isn’t that bad all things considered.
No, but being easier for barely capable techs to cobble something together that “works” in less time is considered an upgrade.
Remember: IT security is a separate cost of doing business. Cutting IT security costs improves the bottom line. Increasing costs for “only” security has no business benefit.