Dear Shawn,
Now I might not understand this issue and what I am proposing might be totally ludicrous but from all I am reading could this be a potential solution:
Create a configuration option that makes all file I/O on the iOS utilize Enhanced Data Protection. Would such an approach suit the stated need or does it again represent a simplistic misunderstanding of the issues?
--
Have A Super Fantastic Day!!
Ekkehard Koch
P.S.: If I can help you in any way business or beyond. Just let me know!
************************************************************************
CONFIDENTIALITY NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2210-2521, is confidential and may be legally privileged. This E-mail contains information that is private, confidential, or is protected by
the attorney-client work product doctrines, and is intended only for the use of the individual(s) named herein. If you are not the intended recipient, be advised that unauthorized use, disclosure, copying, distribution, or the taking of any action in reliance
on this information is strictly prohibited. If you have received this E-mail in error, please immediately notify the sender by replying to this E-mail, and delete the original message and any attachments. Thank you.
************************************************************************
wrote:
Allan,
On Feb 20, 2013, at 4:48 PM, "Marcus, Allan B" < email@hidden> wrote:
I don't think you are getting, or acknowledging, LANL's requirements.
Respectfully, I do understand, but an apology to you if you felt I was not properly acknowledging it. Our discussions on important topics such as these here should always be open and with honest challenges from all sides. No one is trying to skirt the
issues, but rather face the issues head on together to improve on the working computing environments for everyone - as much as possible.
That said, please allow me to address your most recent comments here. I know people must be getting tired of hearing from me on this today, so I'll try to do the best I can here and then allow folks to move on to more pressing communication and other
topics.
This has been good to discuss and I hope folks do not shy away from doing so in the future.
Working with individual app developers is not feasible.
We are not saying this is the ideal situation or one that scales for a single agency to work with every developer offering Apps, but are speaking about the best way to attack this particular problem given the need to mitigate these risks and what is available
today. I will say that many of the App developers that are providing solutions leveraging the Enhanced Data Protection did so solely because they were approached by large customers with specific needs that the developer was willing / able to meet. This lead
those developers to then incorporate those capabilities into their Commercial App Store offerings. It all starts with the developers. As more incorporate this into their Apps the better it is for you and every other customer - regardless of what the vertical
market may be.
For example, I want notes and calendar encrypted. Please tell me who at Apple I speak with to make that happen? I then have to contact Google about Drive. Then I have to talk to DropBox, Microsoft, and potentially hundreds of other developers to get them
to flip a bit on their app? That is not feasible.
Any need a customer has of any platform ultimately results in the customer communicating that to the provider. I hope you would agree that has been what you have been doing all along with your desktop/laptop systems as well over the years -- with Apple,
Microsoft, Google, etc. Effective communication by customers and solid integration of those selected capabilities by vendors is what makes products better equipped to meet the needs of the individuals involved. Coming up with innovative ways to both solve
the problems in a meaningful way and advance the platform is nirvana.
When I say I want a global/system solution to turn it on, I mean int he System App. I wan enhanced data protection for all apps, all the time. Yes, I want the user to have to enter a password to do anything on the device except make an emergency call (or a
regular call by entering the number directly).
I have refrained from bringing up BB, but I will at this time. Their entire phone is FIPS certified.
Folks who know me, expected me to stop here... :-) Respectfully, A Phone is not FIPS Certified. The cryptographic module used by Applications and Services on the device has been FIPS 140-2 Validated - Absolutely! The unfortunately thing about FIPS 140-2
is that it does not involve the review, validation or touch at all on ANY of the Processes, Applications or Devices that USE that cryptography outside of the boundary of the cryptographic module. To say it provides anything more is unfortunately not true.
As I was noting the other day, I product could actually use a FIPS 140-2 Validated Module with a NON-Approve Algorithm - not FIPS 140-2 Compliant at that point. I hope people really would read more about what FIPS 140-2 Validation Promises and what it doesn't
promise. There is so much misinformation about it throughout the community. For most it comes down to a checkmark and once they see a checkmark, it seems to take on a life of its own.
I'll step down from my rant here... :-)
Everything on the phone is encrypted/protected until the user authenticates (that is what I mean by "pre-use" authentication).
If the phone is on, but the user is not logged in, I cannot access any _user_ data on the device. That is what I would like to see for the iPhone. When the phone is on, but the suer is not logged in, I cannot access any user data on the device.
Right now I can copy a file (using itunes) to an app's sandbox on the iPhone/iPad.
That is possible with iTunes only for Applications that have intentionally assigned the ability to share files via itunes. That is a specific API for developers to leverage. It was very necessary back in the days where iTunes was at the heart of all
Comms to the iPhone/iPad/iPod touch. Since iOS 5 broke free from the requirements of being tethered to a computer, value add and use of that has sloped off significantly.
I can then plug the device into any Mac, use iExplorer (or similar tool) and copy that file to the computer. Yes, _if_ the developer had implemented a class key above 7 (I think) that data would be safe, but since App developers generally don't do that,
we have a problem.
I am not sure what the reference is to Class Key above 7, but I think you mean to say the Developers need to protect sensitive files in Class A - "ProtectionComplete". With that I couldn't agree more! We are on the same page with that.
All customers such as yourself have much more power than maybe you are giving yourself credit for. All developers, solutions providers, etc. need paying customers. Customers vote with their money.
Yes, the iOS device _can_ be safe, but that is not good enough for government CUI data. We need for the device to always have the data encrypted, protected, and unavailable unless the user is logged in. hence the need for an App like Good, which degrades the
user experience considerably.
A point of clarification here. Users of an iOS device do not "log" into the device, but rather "unlock" the device. I am not picking on the way you said it here, but using this opportunity to point this out to many who do not know or understand that
point. Each time a user "unlocks" the device, they are providing iOS with a non-stored value which is used as part of the tangled key for unlocking various Class keys. Prior to that "unlock" (while the device is running but is locked) those higher level Class
Keys are unavailable to iOS and hence the Files are unable to be decrypted in any way by the OS or otherwise.
The very good point that you have been making all along is that it only has this great protection of the files, if the developer properly utilizes the iOS provided services. I couldn't agree more with you on this. However, forcing ALL Applications and
their data into "ProtectionComplete" now destroys the possibility of the devices to enable things like receive push mail, notifications (local or remote), alarms, MDM, etc. until the user would unlock the device and launch that specific application. It is
not a usable scenario for the vast majority of users around the world including those in the federal government.
I don't know what magic BB does to allow pushed e-mail, but I assume whatever they are doing it passed muster with the Feds.
Assumption or verification ? :-) Remember, it comes down to risk management.
I hope you understand what I'm requesting. Please let me know if there is a way to implement this, or if Apple has a solution that will be coming out.
Apple is constantly working on raising the bar of data protection, despite users and developers :-), but we will not destroy the user experience. Some may choose to select third-party solutions on top of what iOS provides to achieve a level of assurance
and risk they feel is acceptable. Many of those solutions do negatively impact the user experience, but may be a solution chosen by certain organizations. There will always be value for some in using a value added solution by a third-party. Everyone can't
get everything they need from a single entity - it would be nice, but is not realistic.
With respect to your other message sent later...
Subject: Re: [Fed-Talk] CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP)
Date: February 20, 2013 4:52:13 PM EST
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! :-)
I guess I am not understanding the context of this to be able to properly respond without potentially going off on the wrong path. I am always open to being educated :-)
- Shawn
________________________________________
Shawn Geddis T (703) 264-5103
Security Consulting Engineer C (703) 623-9329
Apple Enterprise Division email@hidden
11921 Freedom Drive, Suite 600, Reston VA 20190-5634
_______________________________________________
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
|