I believe Apple has solved this issue with the keychains.
As for the chicken and egg, it is irrelevant which came first as long as KFC is last! :-)
--
Thanks,
Allan Marcus
Chief IT Architect
Los Alamos National Laboratory
505-667-5666
email@hidden
Allan,
I see a chicken-and-the-egg problem here. Yes, all data is encrypted at least until the device is turned on but some data needs to be decrypted so you can actually enter your passcode. I assume
you're asking for something similar to WinMagic's SecureDoc that operates before any data is decrypted or any Apple applications actually run (EFI boot or similar). I could see this as being a good thing and should would be more difficult to crack even with
physical access to the phone. Am I close?
On Feb 20, 2013, at 11:32 AM, "Marcus, Allan B" < email@hidden> wrote:
Very well stated, and exactly the points I was trying to make. For our
purposes we would like to see all data protected until after a password is
entered. There are thousands of Apps, and we don't want to contact each
App that a user wants to use to determine if they are doing Dp correctly.
In fact, very few that I have contacted use DP. The only list I know of is
at:
http://enterpriseios.com/wiki/List_Apps_Support_Apple_Data_Protection
And you will notice it is painfully small.
Shawn, you asked what out needs are. I believe our desire is for a global
Data Protection setting. Does that make sense?
--
Thanks,
Allan Marcus
Chief IT Architect
Los Alamos National Laboratory
505-667-5666
email@hidden
On 2/20/13 12:03 PM, "Jason Deraleau" <email@hidden> wrote:
Hi Allan,
I think the part you're missing is that all data is encrypted at rest, at
the very least in a way that incorporates the hardware-embedded key. The
nuance is what factors must be in place for the device to facilitate
decryption. Based on what you've written, I think you have it more or
less right conceptually, but not quite right semantically.
You're correct that simply having possession of the device and turning it
on will give you access to any data that is protected only by the
hardware key. That data is protected by a single factor (having the
hardware), which may not be adequate for many types of information (e.g.
sensitive mail messages), but is probably OK for others (e.g. music
library). The device will not allow decryption of data that is stored in
a protection class that incorporates the passcode until the user has
entered his or her passcode. That data is protected by two factors
(having the hardware and knowing the passcode), which is arguably better
than most full-disk encryption implementations (as they typically use a
single factor, knowledge of a password, and thus are more susceptible to
off-device attack).
So to say "My understanding is if the App doesn't implement Data
Protection then the data is not encrypted with the device is on" is not
technically accurate because the data of an app that doesn't use Data
Protection certainly IS encrypted; it's just that you can decrypt it by
having the hardware. That might seem like nitpicking, but it means the
data is much more resilient to off-device attacks. If the attacker tries
to bruteforce off-device, they have to guess the hardware-unique AES-256
key. Thus the attacker is more likely to steal your phone instead of just
copying its data, like they might a laptop hard drive. The victim knows
their data is under attack when the device goes missing. Additionally, it
means the attacker will most likely bruteforce passcode-protected data
on-device, which has far less computing power than what they might be
able to get off-device.
There is no sure way to tell whether an app properly uses Data Protection
classes without examining its source code. Apple does not receive or
distribute source code for App Store submissions, so it's difficult to
determine whether an App Store app implements proper protections. I've
seen customers address this in several ways. For their internally
developed apps, institutions could craft policies and requirements that
specify the use of Data Protection classes that incorporate the passcode.
For apps bought from third party developers, a successful approach I've
seen is for the institution to work directly with the app developer. The
App Store provides a way to contact developers and in many cases the
developers are responsive to the business opportunity of implementing a
requested feature.
--
Jason Deraleau
Consulting Engineer - US Commercial Sales
M: +1 (408) 643-2219 | eM: email@hidden
On Feb 20, 2013, at 12:37 PM, "Marcus, Allan B" <email@hidden> wrote:
Thanks Shawn.
I apologize for my inaccurate nomenclature. When I said "Good
Partition", I meant sandbox. We use the term interchangeably here, but
clearly sandbox is the correct term.
When I spoke of moving data to unprotected areas of the device, I mean
using the "open in" feature to copy data from one application's sandbox
to another (or creating data in an App that doesn't use Data
Protection). So yes, quite a bit of data is protected with Data
Protection, but as I understand it, unless an App has implemented data
protection, the data in that App's sandbox is not encrypted once the
device has been turned on.
The "pre-boot" capability that I spoke of refers to having all the data
on the device encrypted until the device is turned on and the password
is entered. I don't know the correct term for this functionality. Right
now if an app doesn't use Data Protection (and very few do), then data
is unprotected on the device when it's turned on and before the user
enters a password
I believe my understanding of how data is encrypted is not far from
reality, but I happy to be corrected. From my high level understanding
(and I have read those documents), data is not encrypted unless the App
developer implements Data Protection (AfterFirstUnlock). If Data
protection is used (AfterFirstUnlock) and strong password is used (which
can be enforced by policy), then the data is very well protected.
My understanding is if the App doesn't implement Data Protection then
the data is not encrypted with the device is on. This is the major issue
I have with iOS; the fact that data can be on the device is a
non-protected state. Do I have this incorrect?
I also don't understand how I can determine if an app is using Data
Protection, specifically AfterFirstUnlock. Is there a way to tell if a
commercial (App Store) App is using this feature?
One major concern is copying data (open in) to an App that doesn't use
Data Protection. If there were a way to have a global/system feature to
turn on Data Protection for all apps, it would be fantastic and would
resolve this concern.
Please correct me if I'm incorrect.
Also, I noticed you submitted an abstract for NLIT. Thanks. I look
forward to hearing your talk.
--
Thanks,
Allan Marcus
Chief IT Architect
Los Alamos National Laboratory
505-667-5666
email@hidden
From: Shawn Geddis <email@hidden>
Date: Thursday, February 14, 2013 4:00 PM
To: Allan Marcus <email@hidden>
Cc: "Rowe, Walter" <email@hidden>, "email@hidden"
<email@hidden>
Subject: Re: [Fed-Talk] CoreCrypto / CoreCrypto Kernel now in "In -
Review"(CMVP)
On Feb 14, 2013, at 3:43 PM, "Marcus, Allan B" <email@hidden> wrote:
Very helpful. Thanks. Unfortunately, I don't think getting FIPS for
what iOS has now will help us, at lease at LANL.
What is it at LANL that is need that is not provided currently provided
by iOS ? It is important that we hear what those requirements are so as
to ensure we take it all into consideration as we move forward with the
platform.
While it's true that everything is always encrypted, simply turning on
the device makes most of the data available.
No, that is an incorrect statement, but frequently misunderstood by
many. I am not sure you are understanding iOS Data Protection
Architecture just yet. Most of the data is NOT available upon boot -
please do not contribute to the propagation of a statement that simply
is not true. It might be helpful to read the iOS Security architecture
whitepaper to get a better understanding of this - starting on Page 7 -
http://images.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf
When I use the term "pre-use" I was hoping for an iOS version of a
"pre-boot" authentication, where the user has to enter a password
before the data is decrypted
"Pre-boot" on a cell phone or tablet ? Really ? Phones and Tablets
are not desktops,
iOS does enforce NO Access to data until you "unlock" the device when
the data files / keys are marked other than the default Class. This
really is a simply thing for developers. For example, Apple even
enabled the ability for Enterprise Developers to define what Data
Protection level they want as part of the Provision Profile for the
Application - No Coding involved.
This is true when an App is properly using Apple Data Protection,
Correct.
but it is not true for the whole device.
Clearly Incorrect. One such example of explanation is page 11 of the
iOS Security Architecture whitepaper -
http://images.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf
For example, accessibility of Keychain Items by the OS... (subset of
those listed on page 11)
ItemsAccessible
€ Wi-Fi passwordsAfter
First Unlock
€ Mail accountsAfter
First Unlock
€ Exchange accountsAfter
First Unlock
€ VPN passwordsAfter
First Unlock
€ LDAP, CalDAV, CardDAVAfter
First Unlock
€ Social network account tokensAfter
First Unlock
€ Home sharing passwordWhen
Unlocked
€ iTunes backupWhen
Unlocked, non-migratory
€ Safari passwords
When Unlocked
€ iCloud TokenAfter
first unlock
Note that this would require unlocking the device and would clearly
not be available when the device boots up.
I am not sure where you are drawing your false statement from, but it
is not only inaccurate, but misleading to everyone on this list. Please
read, yes read, the documentation and even review independent,
third-party security documents that clearly have articulated this for
several years! For example, take a look at the Fraunhofer SIT Report
(most recent December 5, 2012) - http://sit4.me/ios-keychain-faq
I know other government agencies are using Apple Mail, including
Sandia Na Labs, but I don't agree with their risk assessments.
You are more than entitled to agree or not with anyone's assessment of
risk.
Try a re-read of the supporting documentation and it might surprise you.
Also, since there is no way to validate what level of Apple Data
Protection is being used, or even if it's using it, we cannot trust any
app that claims to be using it. We gotta know.
I noted earlier that Developers can also define the Data Protection in
their Provisioning Profile. This would become the default Class for any
file creation source code that did not already articulate the Data
Protection Class for the file.
Any individual or organization that needs fine-grained details of any
process or file protection on any system they defend or manage should
perform their own Pen Testing...
Finally, since data can be moved into an unprotected area of the
device (the fact there there is an unprotected area is an issue),
An "unprotected area of the device" ? Data is not moved to unprotected
area of the device ... Unless you are talking about RAM for execution
and the graphics for Display...
Where are you arriving at this ? i am very perplexed at the origin of
your information.
we will still have to recommend that users do not move LANL data out
of the Good partition.
An App, whether it is Good or any other App does not have a partition.
ALL Apps are forced into a Sandbox for all runtime and stored resources
-- meaning that each App is isolated to files within its own bundle as
well as runtime resources. There is no such thing as an App Partition
on iOS. Sorry, but again it would appear that you are being fed some
very incorrect and misleading information. It simply is not correct,
anyway you look at it.
ALL Applications, as is Good, have significant restrictions enforced by
iOS. Any Application can also further restrict use and access to its
own data within the App through its own enforcement. Good uses a model
where additional policies provided from an external Policy Service are
indeed further enforced on its own data. That a practice they chose and
you and any other customer can choose to whether it fits your needs or
not. Just please, do not propagate the misinformation that the App has
a "partition".
This greatly limits the functionality of the device.
Quite the contrary.
I appreciate your advocacy on our behalf. I can't imagine how hard it
must be to advocate for a customer base that appears to be a small
percentage of your company's overall market base.
Apple innovates and designs one platform for all of our customers. We
do not splinter the platform, but rather provide the best platform we
know how to for all customers -- no matter who they work for or what
they do. Third-party solutions can also augment the platform to address
edge cases or those not targeted by the platform.
- Shawn
________________________________________
Shawn Geddis
Security Consulting Engineer
Apple Enterprise Division
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Peter Link
Cyber Security Analyst
Cyber Security Program
Lawrence Livermore National Laboratory
PO Box 808, L-315
Livermore, CA 94551-0808
email@hidden
|