Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP))
Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP))
- Subject: Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP))
- From: "Villano, Paul Mr CIV USA TRADOC" <email@hidden>
- Date: Thu, 21 Feb 2013 12:41:24 -0500
Thanks. I agree on the UI issue. That and the fact that the corny slogan "it just works" really is true is what made me an Apple fanboy. (Although I still mutter curses against whomever came up with the voice to text dictionary for within apps and email. It's not the same as SIRI which seems to at least make educated guesses. But the other one pulls up the most bizarre words from the dictionary that few if any would ever use and makes no attempt at grammatical corrections. GRRRR....)
That may apply to the original concern. If there's that kind of "disconnect" it may be more of a management issue where they just don't see the need for the increased security (another update already planned but not advertised?) or have some other motive for not fulfilling it rather than technically not being able to.
-----Original Message-----
From: fed-talk-bounces+paul.villano=email@hidden [mailto:fed-talk-bounces+paul.villano=email@hidden] On Behalf Of Marcus, Allan B
Sent: Thursday, February 21, 2013 12:08 PM
To: email@hidden
Subject: Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP))
No, only the data in the Good sandbox or Apps in the Good Dynamics environment is protected. Any data in any other app that doesn't use Apple Data Protection (ADP) to encrypt the files is not protected and can be accessed before the user unlocks the device. Also, Good's UI is not nearly as good as Apple's UI, which goes to my point that Apple is destroying the user experience by forcing those that need a higher level of data protection to use products like Good. Also, the data protection for data in the Good sandbox and data in other Apps that use ADP is protected with different crypto modules.
--
Thanks,
Allan Marcus
Chief IT Architect
Los Alamos National Laboratory
505-667-5666
email@hidden
On 2/21/13 8:49 AM, "Villano, Paul Mr CIV USA TRADOC"
<email@hidden> wrote:
>Allan I don't understand all of the angst you're perceiving or why you
>think your solution is something new. What you describe sounds like
>what the Army is doing with the Good(e?) solution. The whole reason I
>understood they were chosen was because they follow the paradigm you
>mention of protecting all of the data on the phone, not app by app.
>What am I missing?
>
>-----Original Message-----
>From: fed-talk-bounces+paul.villano=email@hidden
>[mailto:fed-talk-bounces+paul.villano=email@hidden] On
>Behalf Of Marcus, Allan B
>Sent: Thursday, February 21, 2013 10:31 AM
>To: email@hidden
>Subject: Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in
>"In -
>Review"(CMVP))
>
>Again, thanks for the taking the time to answer. I'm not going to let
>this drop. I also have to admit that I'm getting frustrated with the
>pedantic nature of your replies.
>
>As for being pedantic, take for example, your comment regarding login
>vs unlock. Wikipedia describes login as
>
>
>"In computer security, a login or logon refers to the credentials
>required to obtain access to a computer system or other restricted area"
>
>
>I submit that when a user takes an iPhone and enters a password to
>unlock the iPhone, she has done the above. As the iOS device is not a
>multi-user device, there is not a username to identify the user, just
>the password as the credentials to obtain access to a computer system.
>Based on the definition you gave, the user is logging-in as well as unlocking.
>
>I'm going to rant a little now, but I think what I'm saying is fairly
>well agreed upon by anyone on the federal government providing iOS devices.
>
>When talking about working with developers "given the need to mitigate
>these risks and what is available today", I submit the most practical
>solution for the entire federal government is to pressure Apple to
>provide for a complete data protection solution. Any other approach is
>essentially futile. You also spoke of the capability to leverage third
>parties to provide solutions, but IOS is different from Mac and
>Windows. Desktop operating systems are not nearly as locked down as
>iOS. That control, which Apple insists upon, also puts more
>responsibility on Apple to provide solutions, since third parties
>cannot. Whole device data protection (for lack of a better term, and
>not wanting to trigger your Pavlovian response that the device is
>already encrypted) is not a solution a third party can provide on iOS
>(as they can on OS X). The ONLY provider than can provide this is
>Apple.
>
>
>You seemingly managed to ignore my comment
>
>
>
> "When I say I want a global/system solution to turn it on, I mean in
>the 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 will refer to this option as "whole device data protection (T)." WDDP
>is a trademark owned by Allan Marcus and can be licensed for a small
>fee :-) If Apple implemented it, I will sign over the trademark to
>Apple for no fee!
>
>
>The only vendor that can provide this is Apple. I'm sure you have heard
>this request before. You state Apple "we will not destroy the user
>experience".
>For those of use that comply with the FISMA law and use Good, don't you
>think that Apple's lack of whole device data protection has force use
>to "destroy the user experience" by using Good?
>
>Also, please take a few minutes and explain how using data protection
>for all data on the device will "destroy the user experience". I assume
>some things will not work, like certain background syncing or
>processing, but if there were a Yes/No slider in the general System
>panel to turn on "whole device data protection", the user could easily
>be warned that certain things would not work with that option. Apple
>allows the user to turn off cellular, bluetooth, wifi, and a ton of
>other settings that could "destroy the user experience".
>
>
> For example, I submit my iPhone SUCKS when I turn on Airplane mode!
>Why the heck does Apple DESTROY my user experience when I turn turn on
>Airplane mode! My device's user experience is also destroyed when I
>turn off siri. Why does apple allow that, but not whole device data
>protection?
>Apple
>let's me exclude certain data from spotlight searches. I submit that
>when I exclude mail from spotlight searches and then I search and
>forget that I've turned off mail and no mail comes up in a search, my
>iPhone is _broken_.
>
>
>Obviously these are ridiculous assumptions to be made on the part of
>the user. These are options that the user can turn on/off, and once
>on/off the user should not expect those options to function. The same
>can easily be said for whole device data protection option. Let the
>user decide to give up a little functionality to gain the security.
>
>I realize you cannot talk about future features. What I would like to
>hear is who do I have to talk to for this feature to be seriously
>considered for a future iOS?
>
>
>--
>Thanks,
>
>Allan Marcus
>Chief IT Architect
>Los Alamos National Laboratory
>505-667-5666
>email@hidden
>
>From: Shawn Geddis <email@hidden>
>Date: Wednesday, February 20, 2013 4:21 PM
>To: Allan Marcus <email@hidden>
>Cc: "email@hidden" <email@hidden>
>Subject: Re: [Fed-Talk] .. (was: CoreCrypto / CoreCrypto Kernel now in
>"In -
>Review"(CMVP))
>
>
>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...
>
> From: "Marcus, Allan B" <email@hidden>
>
> Subject: Re: [Fed-Talk] CoreCrypto / CoreCrypto Kernel now in "In -
>Review"(CMVP)
>
> Date: February 20, 2013 4:52:13 PM EST
>
> To: "email@hidden" <email@hidden>
>
>
>
>
> 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
_______________________________________________
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