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: "Marcus, Allan B" <email@hidden>
- Date: Thu, 21 Feb 2013 21:33:00 +0000
- Thread-topic: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in "In - Review"(CMVP))
I was speaking of Government Furnished Equipment (GFE).
For BYOD a solution like Good for iOS and Android seems appropriate. The
new BB has a business and personal partition built in. Just saw a demo
yesterday and it looks good. Is it enough to come back? Probably not.
--
Thanks,
Allan Marcus
Chief IT Architect
Los Alamos National Laboratory
505-667-5666
email@hidden
On 2/21/13 11:36 AM, "Villano, Paul Mr CIV USA TRADOC"
<email@hidden> wrote:
>Not directly addressed by "Doctor Dan" :- ) but a corollary point is, who
>owns the data? If I get a smartphone given by the DoD it's reasonable to
>expect they get to dictate what I put on it and how I use it. And I
>probably wouldn't much. But I can guarantee that if it becomes a true
>"bring your own device" (as in, we put an app/apps on a phone you
>purchase yourself) there is no way the public or employees are going to
>allow the DoD to mess with their data and there will be a huge outcry if
>anything turns out missing or a "spy" program is found that takes my
>"private" info from my phone. Or is there privacy anymore?
>
>The one who owns the phone owns the data. Or do they? And if so, is that
>the user? The DoD? The manufacturer? All of the above?
>
>-----Original Message-----
>From: fed-talk-bounces+paul.villano=email@hidden
>[mailto:fed-talk-bounces+paul.villano=email@hidden] On
>Behalf Of Dan Beatty
>Sent: Thursday, February 21, 2013 1:10 PM
>To: email@hidden
>Subject: Re: [Fed-Talk] Š. (was: CoreCrypto / CoreCrypto Kernel now in
>"In - Review"(CMVP))
>
>Greetings Gang,
>Allan has one point about the sandbox issue. However, there is a good
>thing about the Sandbox issue that is kind of being obscured here.
>Namely, owner of the phone v/s owner of the data. The concept has been
>managed by the Common Criteria Interpretation Management Board (CCIMB)
>for some time now.
>
>It is one thing if the Army or any other service is issuing out iPhones
>supported by what ever carrier is contracted at the time. However, if
>the Army is forced to endorse a "bring your own phone" because of some
>public out cry over the budget (penny wise and pound foolish), then we
>need a way to say where safe zones exist on the phone. The app or a
>collection of apps would have to provide some measure of security to
>prevent access by other apps which inevitably would be used by a human.
>That protection has to be strong enough to ensure that if that human is
>not the legitimate owner, that measures can be taken to safeguard the
>information.
>
>As I go back into development mode and setup my dev and test environment,
>one unit test series I would like to have is to test the ADP. Is it
>engaged
>when it should be? Is it blocking? If some bastard stole my iPhone,
>could
>it withstand the jerk trying to break in? How long? I am sure that
>Apple
>also has engineers participating in these efforts. I hope that some way,
>they will let me in.
>
>V/R,
>
>Daniel Beatty, Ph.D.
>Computer Scientist, Detonation Sciences Branch Code 474300D
>1 Administration Circle M/S 1109
>China Lake, CA 93555
>email@hidden
>(LandLine) (760)939-7097
>(iPhone) (806)438-6620
>
>
>
>
>On 2/21/13 9:41 AM, "Villano, Paul Mr CIV USA TRADOC"
><email@hidden> wrote:
>
>> 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-bo
>> unces+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:
>> us.army.mil
>
>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:
>> 0navy.mil
>
>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:
>l
>
>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
_______________________________________________
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