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