709.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:10.316 --> 00:00:13.436 A:middle
>> Welcome to Session
709: Protecting Secrets

00:00:13.436 --> 00:00:17.116 A:middle
with the Keychain If you
have ever used a keychain

00:00:17.116 --> 00:00:20.526 A:middle
or if you think you should,
this is your session; iOS, OS X,

00:00:20.526 --> 00:00:26.766 A:middle
we're quite agnostic here
Let's get started What will you

00:00:26.766 --> 00:00:27.316 A:middle
learn here?

00:00:28.496 --> 00:00:31.346 A:middle
Well, I'll tell you what
keychains are I'll tell you how

00:00:31.346 --> 00:00:35.566 A:middle
to use them There is
iOS specific information

00:00:35.566 --> 00:00:38.726 A:middle
and there is OS X specific
information I'll mark them very

00:00:38.726 --> 00:00:41.476 A:middle
specifically so you know when
to go off and check your tweets

00:00:42.476 --> 00:00:45.576 A:middle
And pointers to more stuff

00:00:45.626 --> 00:00:49.636 A:middle
because there's always
more stuff All right

00:00:49.636 --> 00:00:51.166 A:middle
So why do we have a keychain?

00:00:51.936 --> 00:00:53.356 A:middle
We've actually had one

00:00:53.356 --> 00:00:57.046 A:middle
for a very long time There was
a keychain API and keychains

00:00:57.046 --> 00:01:02.736 A:middle
in Mac OS 9; so long time
There's a lot of small secrets

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:57.046 --> 00:01:02.736 A:middle
in Mac OS 9; so long time
There's a lot of small secrets

00:01:03.006 --> 00:01:04.866 A:middle
that your programs
need to handle --

00:01:05.046 --> 00:01:08.396 A:middle
passwords, account
numbers maybe, PINs --

00:01:09.976 --> 00:01:15.786 A:middle
you want to store them securely,
but you don't want to do

00:01:15.786 --> 00:01:19.256 A:middle
that cryptographic thing
because it sounds dangerous

00:01:19.256 --> 00:01:25.436 A:middle
and it's hard And you really
want to be as particular

00:01:25.436 --> 00:01:28.656 A:middle
as you can about who gets
those little secrets,

00:01:29.036 --> 00:01:32.786 A:middle
not just in terms of which
user, but also which programs

00:01:33.476 --> 00:01:36.206 A:middle
because we all know that not
all programs are is meticulous

00:01:36.206 --> 00:01:42.036 A:middle
with the user's secrets as yours
And you want some assurance

00:01:42.036 --> 00:01:46.486 A:middle
that if the user loses
their laptop or their iPhone

00:01:46.486 --> 00:01:48.306 A:middle
and somebody walks away with it,

00:01:48.306 --> 00:01:52.816 A:middle
those secrets actually
stay secrets That's called

00:01:52.816 --> 00:01:57.846 A:middle
"off-line attack" in
security lingo The control

00:01:57.846 --> 00:01:59.556 A:middle
over these secrets

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:00.406 --> 00:02:03.756 A:middle
in the keychain universe is
always the users This is kind

00:02:03.756 --> 00:02:07.216 A:middle
of important point
to get out of the way

00:02:07.216 --> 00:02:10.506 A:middle
up front These are the user's
secrets These are not your

00:02:10.506 --> 00:02:15.076 A:middle
secrets A keychain doesn't give
you a way of hiding something

00:02:15.246 --> 00:02:20.306 A:middle
from the user of the system
It's just a way for you

00:02:20.306 --> 00:02:23.976 A:middle
to protect the user's secrets
better and more easily And,

00:02:23.976 --> 00:02:26.686 A:middle
of course, we all know,
less code is better

00:02:27.076 --> 00:02:32.306 A:middle
So keychain APIs try to be a
high level API Fewer calls,

00:02:32.676 --> 00:02:35.076 A:middle
fewer parameters for the most
part It may not always seem

00:02:35.076 --> 00:02:36.206 A:middle
that way, but believe me,

00:02:36.206 --> 00:02:40.656 A:middle
the low-level solutions look
a lot worse than this Okay

00:02:40.656 --> 00:02:41.956 A:middle
So what is a keychain?

00:02:42.346 --> 00:02:44.986 A:middle
It's a database I
mean, in its heart,

00:02:45.126 --> 00:02:48.546 A:middle
it's a database It's got rows

00:02:48.546 --> 00:02:50.586 A:middle
which in keychain lingo
are called "items";

00:02:51.176 --> 00:02:52.336 A:middle
and the items have values,

00:02:52.406 --> 00:02:53.636 A:middle
that's where you
put the secrets;

00:02:53.636 --> 00:02:57.346 A:middle
and they have attributes which
is things that you find them by

00:02:57.346 --> 00:03:04.256 A:middle
or that you stick on the side
We call those "metadata."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:57.346 --> 00:03:04.256 A:middle
or that you stick on the side
We call those "metadata."

00:03:04.256 --> 00:03:09.426 A:middle
And keychains are optimized
for storing small secrets

00:03:09.616 --> 00:03:12.476 A:middle
and finding them quickly
That's what they do

00:03:12.476 --> 00:03:13.596 A:middle
for a living You know,

00:03:13.596 --> 00:03:17.726 A:middle
the prototypical example is a
user's password to a website

00:03:17.856 --> 00:03:21.966 A:middle
or some web service or
something else; little secrets,

00:03:22.036 --> 00:03:26.716 A:middle
little individual secrets that
you use one at a time Now,

00:03:26.966 --> 00:03:29.116 A:middle
there is nothing in
the APIs that keeps you

00:03:29.116 --> 00:03:34.276 A:middle
from storing 150,000 secrets in
a keychain, and there's nothing

00:03:34.276 --> 00:03:35.326 A:middle
in the APIs that keeps you

00:03:35.326 --> 00:03:38.366 A:middle
from storing a 50 megabytes
large secret in the keychain

00:03:38.956 --> 00:03:42.076 A:middle
But don't do that because that's
not what the APIs are written

00:03:42.136 --> 00:03:45.676 A:middle
for You can do it, but it will
hurt It will definitely hurt

00:03:45.676 --> 00:03:48.436 A:middle
your program, and it may
hurt the system depending

00:03:48.436 --> 00:03:50.826 A:middle
on the circumstances
So remember,

00:03:50.826 --> 00:03:54.226 A:middle
this is for small secrets
Don't sweat it, you know;

00:03:54.226 --> 00:03:56.316 A:middle
couple hundred bytes is fine,

00:03:57.236 --> 00:04:01.586 A:middle
kilobytes probably fine
Thousands of secrets is fine

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:57.236 --> 00:04:01.586 A:middle
kilobytes probably fine
Thousands of secrets is fine

00:04:01.586 --> 00:04:04.696 A:middle
as long as you're not trying
to iterate through all of them

00:04:04.696 --> 00:04:06.026 A:middle
and pick them up one at a time

00:04:06.026 --> 00:04:08.516 A:middle
in your program while the
user waits So that's kind

00:04:08.516 --> 00:04:11.606 A:middle
of the environment they we're
here for You can stretch this,

00:04:11.926 --> 00:04:17.596 A:middle
just don't overstretch it
Yeah, and this is the point

00:04:17.596 --> 00:04:19.656 A:middle
where somebody always raises
their finger and says,

00:04:19.656 --> 00:04:24.066 A:middle
"I just write it to a file," you
know "I'll encrypt it myself,"

00:04:24.066 --> 00:04:26.176 A:middle
or "Why do I bother anyway?

00:04:26.176 --> 00:04:28.656 A:middle
I'll use ROT-13," you
know "Nobody's going

00:04:28.656 --> 00:04:31.946 A:middle
to find the data Why should
I call these weird APIs

00:04:31.946 --> 00:04:33.146 A:middle
with their weird
security things?"

00:04:35.046 --> 00:04:41.026 A:middle
Well, the keychain APIs give
you canned access control

00:04:41.026 --> 00:04:47.066 A:middle
Essentially, a predefined way
of determining what programs,

00:04:47.726 --> 00:04:50.366 A:middle
and to a certain extent,
what users get at the secret,

00:04:51.836 --> 00:04:56.216 A:middle
and they give you a way of
controlling how your program

00:04:56.216 --> 00:04:59.186 A:middle
and other programs can share
access to these secrets

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:00.626 --> 00:05:04.256 A:middle
If you write your secrets
to a file, then anybody

00:05:04.256 --> 00:05:06.456 A:middle
who gets a hold of the
file has the secret I mean,

00:05:06.456 --> 00:05:07.476 A:middle
they may not know where to look

00:05:07.476 --> 00:05:08.756 A:middle
but eventually they'll
figure it out,

00:05:08.756 --> 00:05:14.816 A:middle
and that's not good Plain
files, there is many,

00:05:14.816 --> 00:05:18.046 A:middle
many ways of scanning
for files in the system

00:05:18.276 --> 00:05:22.666 A:middle
And I don't just mean on OS X
There's ways of finding files

00:05:22.666 --> 00:05:28.646 A:middle
in iOS by Jailbreak or
other ways And besides,

00:05:28.646 --> 00:05:31.016 A:middle
when you start manipulating
this data yourself --

00:05:31.406 --> 00:05:33.766 A:middle
you copy it around, you write it
to a file, you fetch it back -

00:05:34.306 --> 00:05:36.236 A:middle
every time you make a
copy, there's another place

00:05:36.236 --> 00:05:41.636 A:middle
where the secret sits, and once
you lose control of a secret,

00:05:41.716 --> 00:05:44.566 A:middle
once it goes to places where
you didn't realize it was going,

00:05:44.566 --> 00:05:45.766 A:middle
there's no way of
getting it back

00:05:46.706 --> 00:05:51.196 A:middle
because you just wrote
it there Keychain is

00:05:51.336 --> 00:05:54.466 A:middle
about doing the cryptography
right without you having

00:05:54.466 --> 00:05:59.386 A:middle
to think about it And believe me
This is hard It really is very

00:05:59.386 --> 00:06:03.486 A:middle
hard And it's not typically
what you want to spend your time

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:59.386 --> 00:06:03.486 A:middle
hard And it's not typically
what you want to spend your time

00:06:03.486 --> 00:06:05.606 A:middle
on So that's why you want

00:06:05.606 --> 00:06:09.396 A:middle
to bother using the
keychain The less code,

00:06:09.396 --> 00:06:15.676 A:middle
the better So let's start
with the minimum kind

00:06:15.706 --> 00:06:18.646 A:middle
of code you can get away with
if your needs are simple --

00:06:18.916 --> 00:06:19.916 A:middle
you want to store a password,

00:06:19.916 --> 00:06:23.796 A:middle
you want to store a PIN You
can create a keychain item,

00:06:23.796 --> 00:06:26.446 A:middle
which is an entry in this
database that is the keychain,

00:06:26.446 --> 00:06:30.856 A:middle
with a single API call it's
called SecItemAdd It's a core

00:06:30.856 --> 00:06:34.106 A:middle
foundation level API, so
you pass it a CFDictionary

00:06:34.596 --> 00:06:37.856 A:middle
but we're all rather happier
with writing Objective-C code

00:06:37.916 --> 00:06:42.156 A:middle
so I wrote you the sample
code in Objective-C Basically,

00:06:42.156 --> 00:06:44.896 A:middle
what you do is, you make up a
dictionary, you stick in all

00:06:44.896 --> 00:06:47.716 A:middle
of the attributes that
you want the item to have,

00:06:48.056 --> 00:06:49.826 A:middle
you stick in the
value, you say go,

00:06:50.506 --> 00:06:54.346 A:middle
and it goes It returns an
OS status, and you always,

00:06:54.346 --> 00:06:55.806 A:middle
always check the OS status

00:06:55.806 --> 00:06:59.426 A:middle
of course You would never even
think of ignoring an error code

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:00.166 --> 00:07:06.846 A:middle
And that's it If the call
returns no error, zero,

00:07:07.036 --> 00:07:08.706 A:middle
then it worked You now
have a keychain item,

00:07:10.056 --> 00:07:11.846 A:middle
and you don't have to
worry about protecting it

00:07:11.846 --> 00:07:14.666 A:middle
because that's what
the API's for Okay

00:07:14.666 --> 00:07:15.826 A:middle
So how do you get it back?

00:07:16.106 --> 00:07:22.476 A:middle
Oh, one note Just like any
good database, it has a notion

00:07:22.836 --> 00:07:26.686 A:middle
of uniquely identifying items
In the case of these kinds

00:07:26.686 --> 00:07:29.346 A:middle
of items, that's the
service attribute

00:07:29.546 --> 00:07:31.996 A:middle
and the account attribute
And if you're trying

00:07:31.996 --> 00:07:35.446 A:middle
to create another item with the
same service and account values,

00:07:35.476 --> 00:07:39.296 A:middle
it will not work because
these are unique So one

00:07:39.296 --> 00:07:42.266 A:middle
of the errors you can get
back from SecItemAdd is,

00:07:42.396 --> 00:07:44.036 A:middle
this item already
exists so I'm not going

00:07:44.036 --> 00:07:49.116 A:middle
to make you another one So
keep that in mind Uniquing Okay

00:07:49.186 --> 00:07:53.266 A:middle
So this is how you get it
back SecItemCopyMatching,

00:07:53.926 --> 00:07:56.926 A:middle
which is literally what this
does Let me give you a bag

00:07:56.926 --> 00:07:59.986 A:middle
of attributes and I'll
match that against items

00:07:59.986 --> 00:08:03.416 A:middle
in the keychain and I'll give
you back the matching value

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:59.986 --> 00:08:03.416 A:middle
in the keychain and I'll give
you back the matching value

00:08:04.426 --> 00:08:08.756 A:middle
So this is the same
dictionary that you passed in,

00:08:09.526 --> 00:08:11.126 A:middle
with the same attributes,

00:08:11.666 --> 00:08:16.146 A:middle
service attribute an account
attribute You typically pass

00:08:16.146 --> 00:08:17.566 A:middle
in "return data", that is,

00:08:17.566 --> 00:08:21.626 A:middle
give me the value You can also
get back references to items

00:08:21.626 --> 00:08:24.326 A:middle
that let you manipulate the
items themselves And, again,

00:08:24.326 --> 00:08:25.546 A:middle
you check the error code,

00:08:25.546 --> 00:08:29.716 A:middle
it gives you back the value
These values, by the way,

00:08:29.716 --> 00:08:33.476 A:middle
are datas They're not strings Of
course, you know, secrets come

00:08:33.476 --> 00:08:36.785 A:middle
in many different shapes and
forms so keep that one in mind

00:08:38.905 --> 00:08:42.356 A:middle
And that's basically the
tools you have to work

00:08:42.356 --> 00:08:45.456 A:middle
with You can create an item
You can get the value back,

00:08:45.456 --> 00:08:48.646 A:middle
you know Sometimes
it's convenient

00:08:48.646 --> 00:08:51.086 A:middle
to do the other two things
that you typically do

00:08:51.086 --> 00:08:55.446 A:middle
with databases You can change
an existing item That's done

00:08:55.446 --> 00:08:59.176 A:middle
with SecItemUpdate This one
actually takes two dictionaries

00:08:59.236 --> 00:09:02.226 A:middle
because it's sort of a
combination of a lookup

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:59.236 --> 00:09:02.226 A:middle
because it's sort of a
combination of a lookup

00:09:02.226 --> 00:09:06.076 A:middle
and a creation; so it takes
one dictionary that you use

00:09:06.076 --> 00:09:09.176 A:middle
to find the item you want to
update, and another dictionary

00:09:09.176 --> 00:09:10.136 A:middle
with all of the stuff you want

00:09:10.136 --> 00:09:12.556 A:middle
to change It's really
quite straightforward

00:09:13.476 --> 00:09:15.906 A:middle
And we have a call for
deleting, which, again,

00:09:15.906 --> 00:09:18.876 A:middle
you pass a dictionary saying
which item you want to delete

00:09:18.876 --> 00:09:23.746 A:middle
and off it goes and deletes it
Always check your error codes

00:09:23.826 --> 00:09:28.096 A:middle
And there you have it: Keychain
APIs That's all you need to know

00:09:28.646 --> 00:09:32.706 A:middle
When you want to change an
item, a lot of people fall

00:09:32.706 --> 00:09:34.896 A:middle
into that one, really
change the item,

00:09:34.896 --> 00:09:39.606 A:middle
use SecItemUpdate It's sometimes
tempting to go, "Yeah, well,

00:09:39.606 --> 00:09:43.806 A:middle
I'll just delete the old item
I'll make a new one Who's going

00:09:44.826 --> 00:09:45.666 A:middle
to notice?"

00:09:45.796 --> 00:09:50.376 A:middle
Programs will notice because
there are attributes to items

00:09:50.656 --> 00:09:52.456 A:middle
that you may not actually
know about There are --

00:09:52.456 --> 00:09:54.586 A:middle
there may be attributes
to items that don't exist

00:09:54.586 --> 00:09:56.396 A:middle
yet because we'll invent
them in the next version

00:09:56.396 --> 00:09:59.756 A:middle
of the operating system
If you delete an item,

00:09:59.826 --> 00:10:04.066 A:middle
you're throwing everything about
it away You forget about it,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:59.826 --> 00:10:04.066 A:middle
you're throwing everything about
it away You forget about it,

00:10:04.066 --> 00:10:06.616 A:middle
and then you make a new one
and it gets default values

00:10:06.616 --> 00:10:07.806 A:middle
for stuff you don't specify,

00:10:07.996 --> 00:10:10.366 A:middle
and this may not actually
be the same values

00:10:10.366 --> 00:10:13.356 A:middle
that the old item had; so
don't do that If you need

00:10:13.356 --> 00:10:17.246 A:middle
to change an existing keychain
item, use SecItemUpdate

00:10:17.886 --> 00:10:23.126 A:middle
because that way, you
keep the stuff And --

00:10:23.626 --> 00:10:26.126 A:middle
well, if you're in a situation

00:10:26.126 --> 00:10:29.346 A:middle
where you have a
particular place in your UI

00:10:29.946 --> 00:10:34.116 A:middle
where the user gives you
the secret for safekeeping,

00:10:35.216 --> 00:10:38.996 A:middle
then you call SecItemAdd
right there And then

00:10:38.996 --> 00:10:40.406 A:middle
if you have another
place in your code

00:10:40.486 --> 00:10:44.106 A:middle
where you know now you need it,
you call SecItemCopyMatching,

00:10:44.366 --> 00:10:47.986 A:middle
and these calls are
all you need But a lot

00:10:47.986 --> 00:10:52.186 A:middle
of times that's not really
what you want to do A lot

00:10:52.186 --> 00:10:54.156 A:middle
of times you start
to write your program

00:10:54.226 --> 00:10:56.946 A:middle
and it goes something
like, oh, I need to connect

00:10:56.946 --> 00:10:59.446 A:middle
to that website Oh, wait
He says I need a password,

00:10:59.446 --> 00:11:01.326 A:middle
so let's go ask the
user about the password,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:59.446 --> 00:11:01.326 A:middle
so let's go ask the
user about the password,

00:11:01.726 --> 00:11:05.016 A:middle
pop up a dialog or, you
know, something like that,

00:11:05.206 --> 00:11:07.686 A:middle
and the user types
in the password,

00:11:07.686 --> 00:11:09.546 A:middle
you send it to the
website, and that's great

00:11:09.546 --> 00:11:12.316 A:middle
until it happens again and
you ask the user again So, no,

00:11:12.316 --> 00:11:15.076 A:middle
wait I heard this is keychain,
so let's use that keychain

00:11:15.076 --> 00:11:18.586 A:middle
to remember the thing that the
user gave me I call this the

00:11:18.586 --> 00:11:23.096 A:middle
"memory work flow" because it's
really not a store and retrieve

00:11:23.156 --> 00:11:25.236 A:middle
from the user's perspective
The user just want

00:11:25.236 --> 00:11:27.446 A:middle
to remember something
he's already told you once

00:11:28.696 --> 00:11:32.016 A:middle
And this happens often enough
that I wrote up a little bit

00:11:32.016 --> 00:11:36.816 A:middle
of pseudo code just to get you
started with it What you do

00:11:36.816 --> 00:11:39.136 A:middle
in a situation where, oh,
suddenly I need a password,

00:11:39.616 --> 00:11:41.746 A:middle
is the first thing you do is
you look it up in the keychain

00:11:41.936 --> 00:11:45.556 A:middle
in case it's already
there And if that worked,

00:11:45.616 --> 00:11:49.686 A:middle
if the keychain retrieval
succeeds, you just take this

00:11:49.686 --> 00:11:52.066 A:middle
and you use it and you don't
bother the user That's,

00:11:52.066 --> 00:11:56.066 A:middle
after all, the whole point
of this If you don't find it

00:11:56.066 --> 00:11:58.366 A:middle
in the keychain, then go
off and ask the user --

00:11:59.956 --> 00:12:01.896 A:middle
this may be the first
time or, you know,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:59.956 --> 00:12:01.896 A:middle
this may be the first
time or, you know,

00:12:02.076 --> 00:12:04.246 A:middle
something may have
happened to the keychain --

00:12:04.366 --> 00:12:07.876 A:middle
and the user gives you the
password and you try it out,

00:12:07.876 --> 00:12:09.956 A:middle
and if it works, then you
stick it in the keychain

00:12:09.956 --> 00:12:13.726 A:middle
with SecItemAdd so that the
next time when you're running

00:12:13.726 --> 00:12:16.346 A:middle
through the same code flow,
you're hitting the copy matching

00:12:16.346 --> 00:12:19.586 A:middle
at the top and you don't
ask the user again This is

00:12:19.586 --> 00:12:20.456 A:middle
about as straightforward

00:12:20.456 --> 00:12:24.276 A:middle
as it can go The password
you retrieved or the password

00:12:24.276 --> 00:12:27.586 A:middle
that the user gave you may not
actually work The user may have

00:12:27.616 --> 00:12:30.166 A:middle
mistyped it or it may
have been changed;

00:12:30.796 --> 00:12:34.656 A:middle
so you do need code for,
well, that didn't work

00:12:35.586 --> 00:12:37.956 A:middle
And give a little bit of
thought to what you do

00:12:37.956 --> 00:12:44.406 A:middle
when it didn't work Try it first
before you store in the keychain

00:12:45.266 --> 00:12:46.396 A:middle
If it didn't work --

00:12:46.396 --> 00:12:49.536 A:middle
the keychain item you've
retrieved didn't work

00:12:49.536 --> 00:12:50.826 A:middle
and you ask the user
for a new one,

00:12:51.026 --> 00:12:54.936 A:middle
try that one before you go off
and replace it in the keychain

00:12:55.056 --> 00:12:58.576 A:middle
But it's basically your workflow
I didn't put a loop in here

00:12:58.576 --> 00:13:01.386 A:middle
If you want to keep asking
the user three times,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:58.576 --> 00:13:01.386 A:middle
If you want to keep asking
the user three times,

00:13:01.386 --> 00:13:04.476 A:middle
as many of you want, you
know, just add the code,

00:13:04.676 --> 00:13:08.286 A:middle
the obvious code, but that's
basically the idea This is how

00:13:08.286 --> 00:13:11.956 A:middle
to just remember stuff for the
user The only thing the user

00:13:11.956 --> 00:13:15.666 A:middle
notices is that you don't
keep asking the same question,

00:13:15.876 --> 00:13:21.276 A:middle
which is kind of the Apple
thing Couple things to think

00:13:21.276 --> 00:13:24.296 A:middle
about when you build
this workflow: As I said,

00:13:25.136 --> 00:13:27.446 A:middle
don't store a password until
you have some assurance

00:13:27.446 --> 00:13:31.256 A:middle
that it works; It's kind
of silly to store something

00:13:31.256 --> 00:13:35.976 A:middle
that turns out not to be the
right secret If you can at all,

00:13:35.976 --> 00:13:40.066 A:middle
when you try out this password,
this secret, this PIN, whatever,

00:13:41.296 --> 00:13:45.026 A:middle
try to distinguish between
this is the wrong password

00:13:45.326 --> 00:13:49.346 A:middle
and this didn't work There
are programs out there --

00:13:49.346 --> 00:13:51.606 A:middle
and I am trying really
hard not to mention them --

00:13:52.216 --> 00:13:55.386 A:middle
whose response to
network problems is, oh,

00:13:55.386 --> 00:13:56.686 A:middle
that password didn't
work I'll delete it

00:13:56.686 --> 00:13:58.216 A:middle
from the keychain
There Aren't you happy?

00:13:59.026 --> 00:14:03.716 A:middle
No Try to distinguish between
a environmental problems,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:13:59.026 --> 00:14:03.716 A:middle
No Try to distinguish between
a environmental problems,

00:14:03.966 --> 00:14:07.016 A:middle
which basically means you don't
know if the password worked

00:14:07.016 --> 00:14:10.906 A:middle
because you never got there,
and a perfectly good connection

00:14:10.906 --> 00:14:15.266 A:middle
to a service that tells you no,
no, no, that's not good I don't

00:14:15.266 --> 00:14:18.606 A:middle
like your password If the answer
is "I don't like your password,"

00:14:18.686 --> 00:14:20.196 A:middle
then go ask the user
for a new one,

00:14:20.196 --> 00:14:21.946 A:middle
replace it in the
keychain That's good

00:14:22.166 --> 00:14:26.396 A:middle
If the problem you're having is,
I'm having connectivity problems

00:14:26.396 --> 00:14:30.456 A:middle
or the service down, or if
you're not so totally sure,

00:14:30.526 --> 00:14:33.226 A:middle
when in doubt, leave the
old item in the keychain

00:14:34.026 --> 00:14:36.726 A:middle
because if you're not sure that
it's wrong, it's probably better

00:14:36.726 --> 00:14:42.256 A:middle
to keep it Always keep in mind
that in most environments,

00:14:42.256 --> 00:14:45.046 A:middle
particularly with websites,
there's always another way

00:14:45.046 --> 00:14:47.576 A:middle
of changing the password that
doesn't involve your application

00:14:48.676 --> 00:14:52.466 A:middle
So just because everything
worked fine the last time

00:14:52.466 --> 00:14:53.996 A:middle
doesn't mean it's
going to work today

00:14:54.656 --> 00:15:00.806 A:middle
And ask yourself a little bit
how hard it is for the user

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:54.656 --> 00:15:00.806 A:middle
And ask yourself a little bit
how hard it is for the user

00:15:00.806 --> 00:15:05.096 A:middle
to get the stuff back We
security people like to say

00:15:05.096 --> 00:15:08.456 A:middle
that when doubt, erase
the secret and start over

00:15:08.636 --> 00:15:12.706 A:middle
and that's a very good security
rule And if this is a password

00:15:12.706 --> 00:15:14.726 A:middle
that the user probably remembers

00:15:14.726 --> 00:15:18.096 A:middle
and you're just doing
some convenience for him,

00:15:18.096 --> 00:15:20.226 A:middle
then that's good When it
doubt, throw it out --

00:15:20.226 --> 00:15:23.676 A:middle
ask the user But if that happens
to be a password that they have

00:15:23.676 --> 00:15:25.966 A:middle
to get out of their safe and
read it off of a piece of paper

00:15:25.966 --> 00:15:28.636 A:middle
because it's some highly
valuable recovery password,

00:15:29.326 --> 00:15:32.416 A:middle
then maybe you want to
err on the side of keep it

00:15:32.416 --> 00:15:35.336 A:middle
in the keychain unless you're
totally sure that it's wrong

00:15:37.806 --> 00:15:40.666 A:middle
And in all of these
keychain workflows,

00:15:42.266 --> 00:15:46.046 A:middle
have a way to continue working
if everything falls apart

00:15:46.516 --> 00:15:49.356 A:middle
If the keychain APIs just give
you these mysterious error codes

00:15:49.356 --> 00:15:53.266 A:middle
that you've never seen before,
don't just splat on the user

00:15:53.266 --> 00:15:54.996 A:middle
and say, you can't
have your website,

00:15:54.996 --> 00:15:57.806 A:middle
you can't have your
service Always fall back

00:15:57.806 --> 00:16:01.106 A:middle
when everything else fails on
ask the user for the secret

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:57.806 --> 00:16:01.106 A:middle
when everything else fails on
ask the user for the secret

00:16:01.106 --> 00:16:04.546 A:middle
and then feed it out to the
service That's your last

00:16:04.546 --> 00:16:07.776 A:middle
defense; if you build your
workflow, that's always

00:16:07.776 --> 00:16:14.546 A:middle
where you want to end up
if everything else fails.

00:16:14.546 --> 00:16:14.736 A:middle
[ Pause ]

00:16:14.736 --> 00:16:20.166 A:middle
I told you that a keychain item
has a value and attributes,

00:16:20.546 --> 00:16:23.366 A:middle
or metadata Now,
this is important

00:16:24.266 --> 00:16:27.206 A:middle
because it's really the
value we are protecting

00:16:27.206 --> 00:16:31.276 A:middle
with our high-grade
cryptographic munitions The

00:16:31.276 --> 00:16:35.346 A:middle
attributes are what we use to
find stuff with, and that means

00:16:35.346 --> 00:16:38.206 A:middle
that they can't be that
secret, because, after all,

00:16:38.206 --> 00:16:41.216 A:middle
you can look them up in
the keychain to find items

00:16:41.516 --> 00:16:45.336 A:middle
So anything that you want
to store for the user

00:16:45.336 --> 00:16:48.576 A:middle
that the user thinks is a
secret, that the user wants

00:16:48.576 --> 00:16:51.466 A:middle
to keep a secret, needs to
go into the item value not

00:16:51.466 --> 00:16:55.946 A:middle
into attributes Now,
obviously, if it's a password,

00:16:55.946 --> 00:16:58.826 A:middle
it goes in the value If it's
a PIN, it goes in the value

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:00.186 --> 00:17:02.606 A:middle
If it's their name,

00:17:03.376 --> 00:17:05.986 A:middle
it's probably not a secret
It's a good thing to use

00:17:05.986 --> 00:17:10.215 A:middle
as an attribute But sometimes
this is a little bit not

00:17:10.306 --> 00:17:16.616 A:middle
so clear Security people tend to
think of account numbers as not

00:17:16.616 --> 00:17:18.556 A:middle
as secret Social
Security numbers;

00:17:18.556 --> 00:17:22.215 A:middle
let's take a Social Security
number We all know it's not a

00:17:22.215 --> 00:17:25.006 A:middle
secret, and it's pretty easy

00:17:25.006 --> 00:17:26.955 A:middle
to find somebody's
Social Security number

00:17:27.616 --> 00:17:32.556 A:middle
But there are banks and there
are lots of companies who think

00:17:32.556 --> 00:17:35.306 A:middle
that knowing somebody's Social
Security number actually makes a

00:17:35.306 --> 00:17:39.456 A:middle
difference and proves something;
so there is a lot of users

00:17:39.456 --> 00:17:43.126 A:middle
out there who think that
their Social Security number,

00:17:43.126 --> 00:17:45.736 A:middle
if you happen to store
it, should be a secret

00:17:46.996 --> 00:17:49.666 A:middle
So you probably want to make
it a secret and not use it

00:17:49.736 --> 00:17:52.406 A:middle
as an attribute Same thing
with credit card numbers:

00:17:52.956 --> 00:17:55.556 A:middle
Credit card numbers are not
really very good secrets,

00:17:56.466 --> 00:18:00.246 A:middle
but strangely enough, a
lot of banks seem to think

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:56.466 --> 00:18:00.246 A:middle
but strangely enough, a
lot of banks seem to think

00:18:00.246 --> 00:18:04.406 A:middle
that they should be
So think a little bit

00:18:04.406 --> 00:18:07.526 A:middle
about how you are identifying
your keychain items,

00:18:07.526 --> 00:18:09.426 A:middle
because in the end,
in order to find them,

00:18:09.936 --> 00:18:13.026 A:middle
you need to give them attributes
that make them easy to find;

00:18:14.126 --> 00:18:15.476 A:middle
otherwise, you know, you'll end

00:18:15.476 --> 00:18:18.086 A:middle
up with your keychain
being a write once store

00:18:18.086 --> 00:18:24.076 A:middle
and you can't ever get it
back out So if you can come

00:18:24.076 --> 00:18:29.086 A:middle
up with something that you and
the user agree is pretty obvious

00:18:29.686 --> 00:18:32.096 A:middle
and a public identification
of the user

00:18:32.346 --> 00:18:33.636 A:middle
and what the user's
trying to do,

00:18:33.636 --> 00:18:38.336 A:middle
then use that If you have a hard
time coming up with something

00:18:38.336 --> 00:18:41.736 A:middle
that you don't think some user
will think is a disclosure

00:18:42.076 --> 00:18:46.266 A:middle
of dangerous proportions,
your fall back is to make

00:18:46.266 --> 00:18:49.106 A:middle
up something If you can't
think up anything else,

00:18:49.106 --> 00:18:53.116 A:middle
generate a UUID, use that as
a key Of course, then you need

00:18:53.116 --> 00:18:55.306 A:middle
to store that, but
since it's an identifier

00:18:55.306 --> 00:18:57.476 A:middle
that you're only using to
identify the keychain item,

00:18:57.476 --> 00:19:00.486 A:middle
you can just store that
in a key value attribute

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:57.476 --> 00:19:00.486 A:middle
you can just store that
in a key value attribute

00:19:00.716 --> 00:19:03.396 A:middle
in your cloud storage, or in
your file if you're so inclined

00:19:04.266 --> 00:19:07.546 A:middle
So that's your way out of
the "I don't have anything

00:19:07.616 --> 00:19:09.116 A:middle
to tag my keychain items with."

00:19:10.186 --> 00:19:11.726 A:middle
In the end, you can
make something

00:19:13.206 --> 00:19:18.526 A:middle
up This is not really keychain
specific but it's something

00:19:18.526 --> 00:19:22.106 A:middle
that we always tell you The
whole point of having secrets is

00:19:22.156 --> 00:19:26.006 A:middle
that you don't leak
them; so retrieve them

00:19:26.006 --> 00:19:30.566 A:middle
from the keychain right when
you need them, use them,

00:19:30.976 --> 00:19:35.196 A:middle
and then throw them away Do not
keep your secrets in a variable

00:19:35.196 --> 00:19:39.246 A:middle
in memory; do not write your
secrets to a file because it was

00:19:39.296 --> 00:19:42.056 A:middle
so annoying to get them out of
the keychain in the first place;

00:19:43.866 --> 00:19:47.356 A:middle
and do not send them to your
buddy, the helpful XPC service

00:19:47.356 --> 00:19:48.746 A:middle
for the helpful daemon
to hold them

00:19:48.746 --> 00:19:52.136 A:middle
for you The whole keychain
workflow is based on,

00:19:52.306 --> 00:19:55.846 A:middle
just get it, use it, throw it
out Let the keychain hold it

00:19:55.846 --> 00:19:58.216 A:middle
for any time when you don't
actively use the secret

00:19:58.716 --> 00:20:04.036 A:middle
And that's basically all
you need to know in order

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:58.716 --> 00:20:04.036 A:middle
And that's basically all
you need to know in order

00:20:04.036 --> 00:20:07.946 A:middle
to use keychains as
a high-level service

00:20:09.306 --> 00:20:12.976 A:middle
on Apple products Everything
I've told you so far is true

00:20:12.976 --> 00:20:18.216 A:middle
on iOS and OS X Everything I've
told you so far works on both

00:20:19.286 --> 00:20:21.926 A:middle
That is good That's a
really good argument

00:20:21.926 --> 00:20:23.696 A:middle
for using just what
I told you so far

00:20:24.956 --> 00:20:30.086 A:middle
because it works You don't have
to worry about it But, well,

00:20:30.086 --> 00:20:33.956 A:middle
okay Maybe you want to know a
little bit more So let's talk

00:20:33.956 --> 00:20:43.196 A:middle
about iOS first The SecItem APIs
that I told you about are going

00:20:43.196 --> 00:20:45.426 A:middle
to serve you well on iOS
because they're the only API

00:20:45.426 --> 00:20:52.956 A:middle
that is there, so cool If you
store a keychain item on iOS,

00:20:54.336 --> 00:21:03.106 A:middle
it is secured, cryptographically
secured, by the user And by

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:54.336 --> 00:21:03.106 A:middle
it is secured, cryptographically
secured, by the user And by

00:21:03.106 --> 00:21:06.906 A:middle
that we mean, by the PIN or
password that the user enters

00:21:06.906 --> 00:21:11.236 A:middle
to unlock the device That's how
the off-line protection thing

00:21:11.236 --> 00:21:15.086 A:middle
works: If somebody steals
your phone and walks away

00:21:15.086 --> 00:21:19.526 A:middle
with it and, you know, does a
big storage dump of the phone,

00:21:19.526 --> 00:21:23.916 A:middle
if they don't know your passcode
and your phone wasn't jailbroken

00:21:23.916 --> 00:21:28.656 A:middle
to begin with when you lost
it, there is no shortcut other

00:21:28.656 --> 00:21:31.566 A:middle
than brute force attack to
actually get your secrets

00:21:31.566 --> 00:21:38.566 A:middle
out of the keychain You can also
connect keychain items on iOS

00:21:38.656 --> 00:21:42.876 A:middle
to the particular hardware
platform to the instance

00:21:42.876 --> 00:21:46.616 A:middle
of device, which means that it's
also cryptographically linked

00:21:46.686 --> 00:21:50.046 A:middle
to a secret that is embedded --

00:21:50.046 --> 00:21:55.786 A:middle
baked into your particular phone
That's a cool feature, because,

00:21:55.906 --> 00:21:59.166 A:middle
well, it means you can
make secrets that belong

00:21:59.166 --> 00:22:07.366 A:middle
to this particular phone and
non other, and the user On iOS,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:59.166 --> 00:22:07.366 A:middle
to this particular phone and
non other, and the user On iOS,

00:22:07.966 --> 00:22:11.296 A:middle
by default, if you just use
the calls that I showed you,

00:22:11.296 --> 00:22:17.646 A:middle
a keychain item is totally bound
to the application that made it;

00:22:18.836 --> 00:22:24.126 A:middle
so if you write a app and you
call SecItemAdd, no other app

00:22:24.246 --> 00:22:28.566 A:middle
in the universe can
see that item On iOS,

00:22:28.686 --> 00:22:29.486 A:middle
this is done totally

00:22:29.486 --> 00:22:33.416 A:middle
by visibility You basically just
don't see keychain items made

00:22:33.416 --> 00:22:37.426 A:middle
by other applications On the
other hand, if you can see it

00:22:37.606 --> 00:22:39.916 A:middle
and the user has, you
know, unlocked their phone,

00:22:39.916 --> 00:22:41.166 A:middle
then you can actually get them

00:22:41.546 --> 00:22:45.706 A:middle
So this is the fundamental
access control that we're having

00:22:45.706 --> 00:22:48.396 A:middle
on iOS And that's cool
unless, of course,

00:22:48.396 --> 00:22:52.036 A:middle
you want to make a family of
three apps the share a secret --

00:22:52.036 --> 00:22:56.646 A:middle
it's been known to happen --
so we have a way of doing that

00:22:56.646 --> 00:23:01.376 A:middle
And the way you do it is you add
an entitlement It's called the

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:56.646 --> 00:23:01.376 A:middle
And the way you do it is you add
an entitlement It's called the

00:23:01.376 --> 00:23:03.666 A:middle
Keychain-Access-Groups
Entitlement,

00:23:03.856 --> 00:23:08.636 A:middle
and it's basically just a name
that the different apps agree on

00:23:08.636 --> 00:23:11.406 A:middle
and that is used as
a rendezvous point

00:23:12.056 --> 00:23:14.786 A:middle
If you are storing
a keychain item

00:23:14.826 --> 00:23:18.726 A:middle
under a particular
keychain access group name,

00:23:19.136 --> 00:23:21.526 A:middle
then all the applications
that have this entitlement

00:23:21.526 --> 00:23:23.596 A:middle
with that value have access

00:23:23.596 --> 00:23:26.216 A:middle
to the item This is how
you share Obviously,

00:23:26.216 --> 00:23:30.956 A:middle
this is an entitlement so
you can set it up in Xcode

00:23:30.956 --> 00:23:35.206 A:middle
when you build your app And it
wouldn't be much of security

00:23:35.206 --> 00:23:37.706 A:middle
if you could share
it with everybody,

00:23:38.366 --> 00:23:40.686 A:middle
so there are some
restrictions that guarantee

00:23:40.686 --> 00:23:44.836 A:middle
that somebody else will
not come along and say,

00:23:44.906 --> 00:23:47.406 A:middle
"I'll share that with you."

00:23:47.406 --> 00:23:55.336 A:middle
The basic restriction is that
the keychain access group names,

00:23:55.716 --> 00:23:59.596 A:middle
in order to be acceptable
to the store, needs to start

00:23:59.596 --> 00:24:02.806 A:middle
with your team ID So all of
these names are teamID, dot,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:59.596 --> 00:24:02.806 A:middle
with your team ID So all of
these names are teamID, dot,

00:24:02.806 --> 00:24:05.516 A:middle
and then make up something
What this practically means,

00:24:05.516 --> 00:24:08.486 A:middle
of course, is you get to share
whatever you want with yourself,

00:24:08.486 --> 00:24:10.936 A:middle
with your own apps, between
your apps You just don't get

00:24:10.936 --> 00:24:14.276 A:middle
to share them with somebody
else's app Not by accident

00:24:14.276 --> 00:24:18.576 A:middle
and also not on purpose You
just can't Whereby can't,

00:24:18.666 --> 00:24:21.066 A:middle
I mean that you can
build the app like that

00:24:21.066 --> 00:24:27.196 A:middle
but the store take it And if you
are sending out ad hoc copies

00:24:27.356 --> 00:24:29.616 A:middle
of your app to your friends,

00:24:30.066 --> 00:24:32.116 A:middle
you would need a
provisioning profile,

00:24:32.116 --> 00:24:34.116 A:middle
and the provisioning
profiles will not allow you

00:24:34.116 --> 00:24:39.006 A:middle
to have this entitlement So
basically, you can't You get

00:24:39.006 --> 00:24:40.976 A:middle
to share with yourself
between your own apps

00:24:41.116 --> 00:24:45.476 A:middle
and that's all the
sharing you get

00:24:45.696 --> 00:24:49.646 A:middle
In Xcode there's
this little section

00:24:49.646 --> 00:24:51.856 A:middle
in the general configuration

00:24:51.856 --> 00:24:54.576 A:middle
of your app called
keychain Basically,

00:24:54.576 --> 00:24:58.596 A:middle
that's what you add it The
bundle ID of your app acts

00:24:58.656 --> 00:25:00.746 A:middle
as essentially a
keychain access group;

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:58.656 --> 00:25:00.746 A:middle
as essentially a
keychain access group;

00:25:01.086 --> 00:25:04.176 A:middle
so by default you're only
sharing yourself What you do is

00:25:04.176 --> 00:25:07.406 A:middle
you add another value
there and you start sharing

00:25:07.406 --> 00:25:09.106 A:middle
with other apps that
have the same value there

00:25:09.686 --> 00:25:10.836 A:middle
If you're ever wondering

00:25:10.836 --> 00:25:14.636 A:middle
about whether your app actually
has an entitlement like that,

00:25:14.766 --> 00:25:16.976 A:middle
there is the good old
codesign command Of course,

00:25:16.976 --> 00:25:20.866 A:middle
you have to run it on OS X Just
ask it to display entitlements

00:25:20.866 --> 00:25:22.436 A:middle
and you'll get back the plist

00:25:22.436 --> 00:25:29.006 A:middle
that contains your keychain
access groups entitlement You've

00:25:30.536 --> 00:25:33.606 A:middle
probably heard of data
protection I certainly hope

00:25:33.606 --> 00:25:37.156 A:middle
you've heard of data
protection That's iOS's way

00:25:37.576 --> 00:25:43.366 A:middle
of classifying data as to when
it becomes available And one

00:25:43.366 --> 00:25:45.446 A:middle
of the attributes
you can specify

00:25:45.446 --> 00:25:49.326 A:middle
when you create item is its
data protection class So, yes,

00:25:49.326 --> 00:25:53.536 A:middle
each item can have a different
data protection class The

00:25:53.536 --> 00:25:58.006 A:middle
default, if you don't say
anything, is this line,

00:25:58.316 --> 00:26:01.876 A:middle
so you don't have to specify
but you can What that means is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:58.316 --> 00:26:01.876 A:middle
so you don't have to specify
but you can What that means is

00:26:01.876 --> 00:26:04.216 A:middle
that keychain items
can be retrieved

00:26:04.666 --> 00:26:08.556 A:middle
when the phone is unlocked,
which is kind of what you want

00:26:08.806 --> 00:26:12.906 A:middle
If the phone is locked,
well, your code's not running

00:26:13.356 --> 00:26:17.086 A:middle
and then the user loses the
phone and user's very happy

00:26:17.086 --> 00:26:20.296 A:middle
that the keychain item is
not accessible Of course,

00:26:20.626 --> 00:26:22.736 A:middle
if there happens to be a
way of running your app

00:26:22.736 --> 00:26:25.266 A:middle
in the background, as I've
heard maybe there might be,

00:26:26.116 --> 00:26:29.666 A:middle
and you want your app to have
access to a keychain item,

00:26:29.706 --> 00:26:33.236 A:middle
even though the phone's locked
because the user locked it

00:26:33.236 --> 00:26:37.136 A:middle
and walked away, then you
need to weaken the protection

00:26:37.316 --> 00:26:40.556 A:middle
of the item and specify

00:26:40.556 --> 00:26:44.286 A:middle
after first unlock What
this basically means is

00:26:44.456 --> 00:26:47.656 A:middle
that the item is
still not accessible

00:26:47.656 --> 00:26:49.636 A:middle
if the phone got
rebooted or powered off,

00:26:50.216 --> 00:26:52.456 A:middle
but after the user
unlocked it at least once,

00:26:52.456 --> 00:26:55.256 A:middle
even if he locks it after that,
the item is still available

00:26:56.026 --> 00:26:57.856 A:middle
So if you do need
to access an item

00:26:58.256 --> 00:27:02.296 A:middle
from a background activity while
the user is not using the phone,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:58.256 --> 00:27:02.296 A:middle
from a background activity while
the user is not using the phone,

00:27:02.706 --> 00:27:04.866 A:middle
this is what you need to
specify when you make the item

00:27:05.246 --> 00:27:08.126 A:middle
But don't do that unless
that's a situation you're

00:27:08.126 --> 00:27:12.556 A:middle
in because it means that your
item is protected less well It

00:27:12.556 --> 00:27:17.996 A:middle
means that if the user loses his
phone and the thief walks away

00:27:18.376 --> 00:27:22.846 A:middle
and manages to bypass the
lock screen, they might get

00:27:23.976 --> 00:27:30.006 A:middle
at the item If you
are in a situation

00:27:30.006 --> 00:27:36.346 A:middle
where you have background
activity that you need to do

00:27:36.346 --> 00:27:38.186 A:middle
because it's part
of your feature set

00:27:38.236 --> 00:27:39.436 A:middle
because it's really cool

00:27:39.436 --> 00:27:42.016 A:middle
that your code is doing stuff
while the user isn't around,

00:27:42.476 --> 00:27:46.346 A:middle
and you're uncomfortable with
taking the primary password

00:27:46.346 --> 00:27:50.336 A:middle
of the user, the primary secret,
the one that you're safekeeping

00:27:50.336 --> 00:27:52.226 A:middle
for him, and sticking it into

00:27:52.226 --> 00:27:55.886 A:middle
and after first unlock protected
item There's a trick you can use

00:27:55.976 --> 00:27:59.586 A:middle
sometimes, and that is to do
what we call "derive secrets."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:00.196 --> 00:28:04.056 A:middle
If you have control over the
service because, let's say,

00:28:04.056 --> 00:28:06.196 A:middle
you're making it, you're
actually running that service

00:28:06.196 --> 00:28:12.536 A:middle
on the Web, you can
authenticate to it with a secret

00:28:12.676 --> 00:28:18.306 A:middle
that is cryptographically
derived from the real password

00:28:18.306 --> 00:28:22.496 A:middle
of the user The advantage
is that then you can store

00:28:22.496 --> 00:28:26.046 A:middle
that derived password in the
less protected keychain item

00:28:26.456 --> 00:28:28.516 A:middle
and if it gets out
for some reason,

00:28:30.226 --> 00:28:32.056 A:middle
your service can be attacked

00:28:32.356 --> 00:28:33.766 A:middle
with the user's derived
password,

00:28:33.766 --> 00:28:37.496 A:middle
but the user's password is
still secure That matters

00:28:37.496 --> 00:28:39.416 A:middle
because users are
so terribly bad

00:28:39.416 --> 00:28:42.746 A:middle
at reusing passwords
That's extra work,

00:28:42.746 --> 00:28:45.506 A:middle
and it's a little bit beyond
the scope of just talking

00:28:45.506 --> 00:28:48.876 A:middle
about keychains, but I thought
I'd mention it because, well,

00:28:48.876 --> 00:28:55.976 A:middle
it matters What happens
when you backup your phone?

00:28:56.246 --> 00:28:59.156 A:middle
Pretty much what you'd expect
Your keychains get backed

00:28:59.156 --> 00:29:02.956 A:middle
up along with the phone as long
as your backups are encrypted --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:59.156 --> 00:29:02.956 A:middle
up along with the phone as long
as your backups are encrypted --

00:29:02.956 --> 00:29:05.326 A:middle
and all of your backups
are encrypted, right?

00:29:06.236 --> 00:29:09.096 A:middle
You can restore them back onto
the phone and you will get all

00:29:09.096 --> 00:29:11.326 A:middle
of the items back that
were in the keychain

00:29:11.326 --> 00:29:12.376 A:middle
when the backup was made;

00:29:12.576 --> 00:29:17.306 A:middle
so this is totally
seamless it just works Items

00:29:17.456 --> 00:29:21.426 A:middle
that were marked as belonging to
a particular piece of hardware,

00:29:21.426 --> 00:29:25.966 A:middle
to a particular device, can
be restored to that device,

00:29:25.966 --> 00:29:29.166 A:middle
and that will work fine If you
are migrating to another device,

00:29:29.656 --> 00:29:33.726 A:middle
then, by the nature of their
security, they won't come along

00:29:34.326 --> 00:29:38.866 A:middle
So if you are -- if the user
is migrating to another device

00:29:39.396 --> 00:29:40.496 A:middle
and they're restoring a backup,

00:29:41.106 --> 00:29:43.156 A:middle
they will essentially get
a keychain that has all

00:29:43.156 --> 00:29:47.516 A:middle
of the device specific keychain
items missing Be prepared

00:29:47.516 --> 00:29:51.796 A:middle
for these items to disappear in
what seems to be a random moment

00:29:51.796 --> 00:29:56.816 A:middle
in time because the user just
bought a new iPhone something

00:29:56.816 --> 00:30:01.646 A:middle
All right This all
looks perfectly,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:56.816 --> 00:30:01.646 A:middle
All right This all
looks perfectly,

00:30:01.646 --> 00:30:02.996 A:middle
so there will be no need

00:30:02.996 --> 00:30:07.256 A:middle
to debug anything
That's a good thing

00:30:07.256 --> 00:30:13.946 A:middle
because here's the bad news:
There is on iOS no tool

00:30:14.216 --> 00:30:18.106 A:middle
for introspecting the keychain
data There is no command line

00:30:18.106 --> 00:30:22.916 A:middle
tool, because where would you
run it; and there is no utility

00:30:22.916 --> 00:30:26.066 A:middle
that has access to all of
the keychain items of all

00:30:26.066 --> 00:30:29.906 A:middle
of the applications on your
phone That's actually a security

00:30:29.906 --> 00:30:35.236 A:middle
feature Remember that the
access control on iOS is based

00:30:35.236 --> 00:30:37.906 A:middle
on you can only see keychain
items made by your app

00:30:39.096 --> 00:30:44.346 A:middle
So if Apple wrote a utility
for inspecting your keychain,

00:30:45.166 --> 00:30:47.856 A:middle
it would only see the
keychain items that it wrote,

00:30:48.356 --> 00:30:54.066 A:middle
which is kind of pointless
So this being the bad news,

00:30:54.246 --> 00:30:58.616 A:middle
the tip is, you need to put
your debugging code inside

00:30:58.616 --> 00:31:01.526 A:middle
of your app because only
code that's running inside

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:58.616 --> 00:31:01.526 A:middle
of your app because only
code that's running inside

00:31:01.526 --> 00:31:03.476 A:middle
of your app actually can
see the keychain items

00:31:03.476 --> 00:31:07.656 A:middle
that you're having trouble
with You all know how

00:31:07.656 --> 00:31:11.376 A:middle
to put debug code in your
program, and you know,

00:31:11.806 --> 00:31:14.526 A:middle
you know what kind of debug
code you're comfortable

00:31:15.696 --> 00:31:20.306 A:middle
with One thing: If you
actually ship your debug code

00:31:20.766 --> 00:31:23.196 A:middle
in some neat, tricky little --

00:31:23.196 --> 00:31:26.316 A:middle
if you triple tap over there
while holding the phone

00:31:26.386 --> 00:31:28.576 A:middle
sideways, and then a
new debug menu pops up

00:31:28.576 --> 00:31:29.726 A:middle
and you can actually figure

00:31:29.726 --> 00:31:32.316 A:middle
out why the keychains aren't
working, tell App Review

00:31:32.666 --> 00:31:34.536 A:middle
because otherwise they
might get the idea

00:31:34.536 --> 00:31:37.016 A:middle
that you have a secret
feature in your phone

00:31:37.016 --> 00:31:38.686 A:middle
that you don't want
people to know about

00:31:38.686 --> 00:31:40.866 A:middle
and that would be
sad Debugging tip:

00:31:42.276 --> 00:31:44.636 A:middle
When you are passing
these dictionaries

00:31:44.716 --> 00:31:47.776 A:middle
to the keychain APIs,
particularly for Add,

00:31:49.146 --> 00:31:56.376 A:middle
understand that these entries
in those dictionaries fall

00:31:56.376 --> 00:32:01.026 A:middle
into two classes There are the
values that become attributes

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:56.376 --> 00:32:01.026 A:middle
into two classes There are the
values that become attributes

00:32:01.186 --> 00:32:04.996 A:middle
and item values They're data
They are stuff that goes

00:32:04.996 --> 00:32:10.756 A:middle
into the item And then there are
other keys that are control keys

00:32:10.756 --> 00:32:14.436 A:middle
that say what you want to
happen Like the storage class

00:32:14.516 --> 00:32:20.206 A:middle
as an example If you
reuse those dictionaries

00:32:20.306 --> 00:32:24.416 A:middle
between the ItemAdd call
and the CopyMatching call

00:32:24.416 --> 00:32:29.936 A:middle
and the Update call be really
careful because all of the keys

00:32:29.936 --> 00:32:34.626 A:middle
in your dictionary may not
all be useful and valuable

00:32:34.626 --> 00:32:38.756 A:middle
on all the API calls It may
actually be safer to make

00:32:38.756 --> 00:32:41.166 A:middle
up these dictionaries
from scratch for each call

00:32:42.426 --> 00:32:45.876 A:middle
And if you run into any problems
where the APIs are yelling

00:32:45.876 --> 00:32:47.826 A:middle
at you and telling you
that you are just having a

00:32:47.826 --> 00:32:49.876 A:middle
"parameter error"@, something

00:32:49.876 --> 00:32:51.356 A:middle
that just doesn't
make any sense other

00:32:51.356 --> 00:32:52.826 A:middle
than I don't know what
you're talking about,

00:32:53.586 --> 00:32:57.736 A:middle
that often means one of
the keys that you passed

00:32:57.736 --> 00:33:05.566 A:middle
in doesn't make a sense here
so And that's it for iOS Hey,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:57.736 --> 00:33:05.566 A:middle
in doesn't make a sense here
so And that's it for iOS Hey,

00:33:06.186 --> 00:33:10.226 A:middle
that's great Welcome back
OS X crowd The keychain

00:33:10.226 --> 00:33:13.906 A:middle
on OS X has been
around for much longer,

00:33:14.566 --> 00:33:19.496 A:middle
and we have a lot more API and
a lot more complexity simply

00:33:19.496 --> 00:33:22.376 A:middle
because it's been around that
much longer So let me tell you

00:33:22.376 --> 00:33:26.256 A:middle
about it The SecItem APIs
that I've told you about work

00:33:26.556 --> 00:33:30.946 A:middle
on OS X, and they are what you
-- what we want to use Honestly,

00:33:30.996 --> 00:33:35.336 A:middle
seriously, if you can at all,
please use the SecItem APIs

00:33:35.366 --> 00:33:36.456 A:middle
to work with your keychains

00:33:36.876 --> 00:33:40.866 A:middle
because that's what all the
new work goes If there's a bug

00:33:40.866 --> 00:33:42.896 A:middle
in them, we'll fix it much --

00:33:42.896 --> 00:33:47.376 A:middle
with much more alacrity than
in the older APIs So try

00:33:47.376 --> 00:33:50.046 A:middle
that first There
are some things --

00:33:50.046 --> 00:33:51.246 A:middle
and I'll tell you about them --

00:33:52.296 --> 00:33:54.836 A:middle
that you cannot do with
the SecItem APIs on OS X

00:33:54.836 --> 00:33:56.766 A:middle
and then you'll have
to fall back

00:33:56.946 --> 00:34:00.416 A:middle
on the older APIs we
call SecKeychain APIs

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:56.946 --> 00:34:00.416 A:middle
on the older APIs we
call SecKeychain APIs

00:34:00.416 --> 00:34:05.636 A:middle
because they are all folded
around the SecKeychain calls

00:34:05.796 --> 00:34:09.295 A:middle
in the API suite These are not
deprecated They are supported

00:34:09.295 --> 00:34:13.616 A:middle
API They are just not where
we're putting the new cool stuff

00:34:13.926 --> 00:34:21.656 A:middle
On OS X a keychain is a file
in the file system Seriously,

00:34:22.005 --> 00:34:24.835 A:middle
if you look in your home
directory in Library Keychains,

00:34:24.835 --> 00:34:28.275 A:middle
there's a file in there, it's
called login.keychain That's

00:34:28.275 --> 00:34:35.766 A:middle
where your secrets sit It's just
a file So just deal with that

00:34:36.366 --> 00:34:41.335 A:middle
That means that standard
file access controls apply

00:34:41.505 --> 00:34:45.166 A:middle
to keychains Your
login.keychain is owned by you,

00:34:45.166 --> 00:34:48.636 A:middle
it's not generally readable
or writable by other users

00:34:49.275 --> 00:34:50.846 A:middle
And if you mess with
permissions,

00:34:50.996 --> 00:34:52.856 A:middle
you can actually mess up access

00:34:52.856 --> 00:34:59.846 A:middle
to your keychain OS X keychains
are cryptographically protected

00:34:59.996 --> 00:35:04.006 A:middle
by the user's login
password Just like on iOS,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:34:59.996 --> 00:35:04.006 A:middle
by the user's login
password Just like on iOS,

00:35:04.006 --> 00:35:07.026 A:middle
they are protected by the
users PIN or, you know,

00:35:07.146 --> 00:35:09.996 A:middle
the password they entered to
unlock the phone; on OS X,

00:35:09.996 --> 00:35:12.176 A:middle
they're protected by the
password the user uses to log

00:35:12.176 --> 00:35:19.616 A:middle
in Makes perfect sense Now,
while on iOS the default is

00:35:19.616 --> 00:35:22.196 A:middle
that there's no sharing and
you have to do a special thing

00:35:22.196 --> 00:35:24.496 A:middle
to start sharing
between applications,

00:35:25.246 --> 00:35:31.026 A:middle
on OS X keychains
-- keychain items

00:35:31.026 --> 00:35:34.356 A:middle
of one user are all visible
to all applications run

00:35:34.356 --> 00:35:37.226 A:middle
by that user Remember,
OS X multiuser files,

00:35:37.226 --> 00:35:40.206 A:middle
Posix permissions, all of
that stuff So OS X sort

00:35:40.206 --> 00:35:42.256 A:middle
of has the reverse
logic: Instead of starting

00:35:42.256 --> 00:35:44.856 A:middle
with you can't even see
any items that aren't yours

00:35:44.856 --> 00:35:46.306 A:middle
and then you'll have
to do special things

00:35:46.306 --> 00:35:47.236 A:middle
to make them visible,

00:35:47.976 --> 00:35:50.166 A:middle
OS X's approach is you
can see all the items made

00:35:50.166 --> 00:35:53.606 A:middle
by all the applications for
that user, and then we put

00:35:53.606 --> 00:35:55.626 A:middle
on controls that determine

00:35:55.626 --> 00:35:58.176 A:middle
which applications
actually are allowed

00:35:58.176 --> 00:36:00.946 A:middle
to retrieve the item
The way this is done is

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:58.176 --> 00:36:00.946 A:middle
to retrieve the item
The way this is done is

00:36:00.946 --> 00:36:05.126 A:middle
with access control lists Every
Keychain item on OS X has an ACL

00:36:06.506 --> 00:36:09.876 A:middle
And the ACL says what
applications are allowed

00:36:10.286 --> 00:36:16.166 A:middle
to retrieve the value You set
the ACL when you create the item

00:36:16.556 --> 00:36:18.236 A:middle
If you don't specify
anything in particular,

00:36:18.236 --> 00:36:20.846 A:middle
you'll get pretty much exactly
the behavior you'd expect,

00:36:20.846 --> 00:36:22.946 A:middle
which is that the creating
application is the only one

00:36:22.946 --> 00:36:27.166 A:middle
that is allowed to retrieve the
item So the default behavior

00:36:27.166 --> 00:36:29.636 A:middle
on iOS and OS X is very similar

00:36:30.996 --> 00:36:35.716 A:middle
but the machinery is very
different There are calls

00:36:35.776 --> 00:36:37.396 A:middle
for changing the ACL

00:36:37.396 --> 00:36:41.986 A:middle
of an existing item I do
not recommend you use them

00:36:42.506 --> 00:36:44.446 A:middle
because they are
pretty complicated

00:36:45.006 --> 00:36:48.056 A:middle
and the system will throw
up a dialog to confirm

00:36:48.056 --> 00:36:50.096 A:middle
that you actually
wanted to change the ACL,

00:36:50.096 --> 00:36:52.086 A:middle
which is usually not a
very good user experience

00:36:52.726 --> 00:36:57.156 A:middle
So the 98 percent takeaway
rule is: Create the ACLs right

00:36:57.156 --> 00:36:59.206 A:middle
when you create the item
and then forget about them

00:36:59.206 --> 00:37:03.466 A:middle
So what is in these ACLs
An access control list

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:36:59.206 --> 00:37:03.466 A:middle
So what is in these ACLs
An access control list

00:37:03.466 --> 00:37:05.746 A:middle
on a keychain item
is essentially a list

00:37:05.746 --> 00:37:09.336 A:middle
of applications that are allowed
to access the item As I said,

00:37:09.336 --> 00:37:12.466 A:middle
by default, it's the creating
application, but you can,

00:37:12.466 --> 00:37:16.326 A:middle
when you make the item, make a
list and say, me and that app

00:37:16.326 --> 00:37:19.256 A:middle
over there and that third
app over there; and on OS X,

00:37:19.256 --> 00:37:23.216 A:middle
that doesn't have to be your
own You can, if you want,

00:37:23.216 --> 00:37:26.016 A:middle
create an item and say, "and
Safari has access to this item."

00:37:26.296 --> 00:37:27.436 A:middle
I'm not sure why
you would want to

00:37:27.436 --> 00:37:33.066 A:middle
but you can System does The
APs are SecAccess, SecACL,

00:37:33.066 --> 00:37:36.266 A:middle
and SecTrustedApplication,
if you are unfortunate enough

00:37:36.266 --> 00:37:38.956 A:middle
to have to do this, go
read the documentation,

00:37:39.586 --> 00:37:43.856 A:middle
which is public documentation
on the keychain, and it's,

00:37:44.096 --> 00:37:47.136 A:middle
you know, pretty good actually
Here is one other distinction

00:37:48.166 --> 00:37:50.736 A:middle
that is important
between iOS and OS X:

00:37:51.416 --> 00:37:55.736 A:middle
On iOS if you don't have access
to an item, you don't see it,

00:37:55.736 --> 00:37:56.766 A:middle
you can't do anything with it,

00:37:56.766 --> 00:38:00.446 A:middle
end of story There's just no
discussion On OS X if you're

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:56.766 --> 00:38:00.446 A:middle
end of story There's just no
discussion On OS X if you're

00:38:00.446 --> 00:38:02.936 A:middle
in an application that
doesn't have access to an item

00:38:03.206 --> 00:38:07.316 A:middle
because it's not on the access
control list and you try anyway,

00:38:07.846 --> 00:38:11.326 A:middle
the system will try to put up a
dialog Now, you've probably seen

00:38:11.326 --> 00:38:15.536 A:middle
that one We lovingly call it
the "rogue application alert"

00:38:15.536 --> 00:38:18.166 A:middle
because it's the system saying,
hey, this program wants access

00:38:18.166 --> 00:38:20.916 A:middle
to the item and I don't think
it should, but do you want

00:38:20.916 --> 00:38:23.436 A:middle
to allow it anyway So on OS X,

00:38:23.796 --> 00:38:25.326 A:middle
the user actually
has the ability

00:38:25.326 --> 00:38:29.616 A:middle
to override your access control
list by saying, yes, I want it

00:38:29.706 --> 00:38:32.906 A:middle
and it's my secret and
he can have it So keep

00:38:32.906 --> 00:38:39.076 A:middle
that in mind There is a
separate keychain file

00:38:39.076 --> 00:38:42.906 A:middle
on OS X that's called the
system keychain It's in /Library

00:38:42.906 --> 00:38:48.116 A:middle
because it belongs to the system
And the system keychain belongs

00:38:48.116 --> 00:38:50.936 A:middle
to the system as a whole It's
a multiuser operating system,

00:38:50.936 --> 00:38:54.416 A:middle
remember If you write
a system daemon

00:38:55.116 --> 00:38:59.416 A:middle
and you use the keychain APIs,
that's where your secrets go

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:00.706 --> 00:39:02.926 A:middle
But the system keychain
is actually accessible

00:39:03.076 --> 00:39:06.576 A:middle
to every program in the system
So if you're in a situation

00:39:06.576 --> 00:39:10.076 A:middle
where you need to create a
keychain item that is shared

00:39:10.076 --> 00:39:13.396 A:middle
between users, you
want that secret to go

00:39:13.396 --> 00:39:14.376 A:middle
into the system keychain,

00:39:14.376 --> 00:39:17.066 A:middle
because the system keychain
can be read by every user

00:39:17.066 --> 00:39:20.406 A:middle
on the system That's a
capability that, well,

00:39:20.406 --> 00:39:25.826 A:middle
OS X has Of course, the
system keychain does belong

00:39:25.826 --> 00:39:28.466 A:middle
to the system as a whole,
so asking a user, hey,

00:39:28.466 --> 00:39:31.826 A:middle
do you want this
program to have access

00:39:31.826 --> 00:39:34.436 A:middle
to that system secret
wouldn't be very fair

00:39:34.436 --> 00:39:36.966 A:middle
if the user isn't perhaps
even an administrator;

00:39:37.436 --> 00:39:40.226 A:middle
so if that happens to a
secret in the system keychain,

00:39:40.226 --> 00:39:41.776 A:middle
we're not just asking,
is this okay

00:39:41.776 --> 00:39:43.416 A:middle
to do this We're
actually asking, hey,

00:39:43.416 --> 00:39:44.786 A:middle
prove that you're
an administrator

00:39:45.806 --> 00:39:50.376 A:middle
So the keychain dialog
for overriding ACL control

00:39:51.406 --> 00:39:59.356 A:middle
for the system keychain is an
admin check Let's talk a little

00:39:59.356 --> 00:40:03.476 A:middle
bit more about these prompts
There's a particular error code,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:59.356 --> 00:40:03.476 A:middle
bit more about these prompts
There's a particular error code,

00:40:03.536 --> 00:40:08.336 A:middle
one of the OSStatus values that
can come out of a keychain call,

00:40:09.066 --> 00:40:11.596 A:middle
it's called "user
interaction not allowed."

00:40:12.746 --> 00:40:16.646 A:middle
And a lot of people get
very confused by it; like,

00:40:16.646 --> 00:40:17.796 A:middle
what user interaction?

00:40:17.796 --> 00:40:22.146 A:middle
I did want any user interaction
I just want the item What this

00:40:22.176 --> 00:40:26.536 A:middle
means is, I needed to put up a
dialog to get you what you want

00:40:26.536 --> 00:40:29.846 A:middle
and I couldn't Well, why would
the system put up a dialog?

00:40:29.846 --> 00:40:33.676 A:middle
We've already had one situation
If the application isn't

00:40:33.706 --> 00:40:37.476 A:middle
on the ACL approved
list, if it's an intruder

00:40:37.476 --> 00:40:40.376 A:middle
and an interloper that
is trying to get an item

00:40:40.446 --> 00:40:44.146 A:middle
that the ACL says it shouldn't
have, system tries to put

00:40:44.146 --> 00:40:48.286 A:middle
up a dialog The other
situation is for keychains

00:40:48.396 --> 00:40:52.106 A:middle
that are not actually at the
moment unlocked Remember,

00:40:52.106 --> 00:40:54.116 A:middle
I told you that the
cryptographic protection

00:40:54.116 --> 00:40:56.776 A:middle
of a keychain is based on
the user's login password?

00:40:57.506 --> 00:41:01.466 A:middle
When you log in through the
standard OS X login screen,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.506 --> 00:41:01.466 A:middle
When you log in through the
standard OS X login screen,

00:41:01.796 --> 00:41:04.376 A:middle
the password you type in
that allows you to log

00:41:04.376 --> 00:41:06.146 A:middle
into the system is also used

00:41:06.286 --> 00:41:10.846 A:middle
to unlock the user's keychain
The passwords are in sync

00:41:10.846 --> 00:41:12.816 A:middle
As a matter of fact, when
you change your pass --

00:41:12.816 --> 00:41:16.366 A:middle
your login password, it actually
changes the cryptographically

00:41:16.496 --> 00:41:22.816 A:middle
secured password on the login
keychain at the same time

00:41:23.046 --> 00:41:24.406 A:middle
So it's always unlocked, right?

00:41:25.336 --> 00:41:27.366 A:middle
So why would the system
ever need to ask for it?

00:41:27.706 --> 00:41:30.156 A:middle
Because there are
preferences for paranoid people

00:41:30.156 --> 00:41:33.126 A:middle
where you can actually say
that you want your keychain

00:41:33.676 --> 00:41:39.516 A:middle
to lock automatically after
inactivity And some people turn

00:41:40.416 --> 00:41:44.746 A:middle
that on Yeah, I do
At which point

00:41:44.746 --> 00:41:47.736 A:middle
if you then asking the
keychain API for an item

00:41:48.236 --> 00:41:50.726 A:middle
and the keychain is locked at
this point, the system will put

00:41:50.726 --> 00:41:53.206 A:middle
up a dialog and say, Could you
please enter that password again

00:41:53.206 --> 00:41:54.026 A:middle
because you're paranoid?

00:41:54.686 --> 00:41:58.506 A:middle
Which is fine as long
as this dialog can come

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:00.546 --> 00:42:04.246 A:middle
up If your program is not
running in a graphic context,

00:42:05.326 --> 00:42:08.406 A:middle
meaning, if it doesn't
have the ability to put

00:42:08.406 --> 00:42:12.526 A:middle
up standard CocoaDialogs,
the system knows that --

00:42:12.526 --> 00:42:16.086 A:middle
the keychain system knows
that, and in any situation

00:42:16.086 --> 00:42:18.206 A:middle
where it's trying to put up
a dialog on your behalf --

00:42:18.206 --> 00:42:21.476 A:middle
from the user's behalf and it
can't, instead the call fails

00:42:21.476 --> 00:42:22.706 A:middle
and that's the error
code you're getting --

00:42:22.706 --> 00:42:26.586 A:middle
user interaction not allowed I
was trying to talk to the user

00:42:26.586 --> 00:42:29.066 A:middle
and ask him if it's
okay but I couldn't

00:42:29.906 --> 00:42:32.836 A:middle
So what this really means, what
this error code really means

00:42:32.836 --> 00:42:36.386 A:middle
to you, is you are in a
nongraphical environment

00:42:36.386 --> 00:42:38.676 A:middle
for some reason You
are in the cron job,

00:42:38.736 --> 00:42:39.966 A:middle
you are in the system daemon,

00:42:40.246 --> 00:42:44.866 A:middle
you SSHed into the system SSHing
does not get you graphical

00:42:44.866 --> 00:42:47.656 A:middle
access even if you are
logged in as the same user

00:42:47.656 --> 00:42:50.396 A:middle
at the same time on the same
Mac They are totally separate

00:42:50.396 --> 00:42:53.636 A:middle
security sessions So keep
this in mind because that's

00:42:53.636 --> 00:42:56.666 A:middle
like probably 50 to
80 percent of all

00:42:56.666 --> 00:43:00.726 A:middle
of the problems people have
So what do you do if you're

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:56.666 --> 00:43:00.726 A:middle
of the problems people have
So what do you do if you're

00:43:00.726 --> 00:43:02.006 A:middle
in a nongraphical context?

00:43:02.006 --> 00:43:05.286 A:middle
You want to use the keychain
anyway There are API calls

00:43:05.286 --> 00:43:09.436 A:middle
and the SecKeychain APIs that
allow you to unlock the keychain

00:43:10.236 --> 00:43:12.756 A:middle
Of course, you'll have to say,
"and the password is this"

00:43:12.876 --> 00:43:18.326 A:middle
because you can't put up
a dialog There are APIs

00:43:18.456 --> 00:43:21.756 A:middle
for retrieving items and
all of this good stuff;

00:43:21.756 --> 00:43:24.906 A:middle
so if you happen to have
the user's login password

00:43:24.906 --> 00:43:27.366 A:middle
or whatever secret protects
the keychain, you can just pass

00:43:27.416 --> 00:43:31.156 A:middle
that to API But if you have a
command that normally works fine

00:43:31.156 --> 00:43:34.056 A:middle
from terminal but now you want
to use it from an SSH session,

00:43:34.576 --> 00:43:37.056 A:middle
the easiest way is to use
the security command That's a

00:43:37.056 --> 00:43:40.086 A:middle
command line command, it's the
Swiss Army keychain command

00:43:41.376 --> 00:43:43.486 A:middle
And it has an option for "I want

00:43:43.486 --> 00:43:45.836 A:middle
to unlock this keychain
now Here's the password."

00:43:46.726 --> 00:43:51.336 A:middle
So most of the time if the
problem is unlocking keychains,

00:43:51.336 --> 00:43:54.916 A:middle
just running security unlock
before you run your program will

00:43:54.916 --> 00:43:59.526 A:middle
get you out of your
hole If the problem is

00:43:59.526 --> 00:44:02.176 A:middle
that your application isn't
on the access control list

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.526 --> 00:44:02.176 A:middle
that your application isn't
on the access control list

00:44:02.176 --> 00:44:05.686 A:middle
of the item, well, that's your
mistake You should have created

00:44:05.686 --> 00:44:09.056 A:middle
the item with the right ACL to
begin with And I should mention

00:44:09.056 --> 00:44:11.536 A:middle
that when we're talking about
application identity here,

00:44:11.536 --> 00:44:13.716 A:middle
these are codesigning identities

00:44:14.456 --> 00:44:16.906 A:middle
And I am glad everybody
here is signing their code

00:44:16.906 --> 00:44:19.796 A:middle
because the keychain stuff
system doesn't work very well

00:44:19.796 --> 00:44:23.056 A:middle
if your programs
unsigned anymore Well,

00:44:23.056 --> 00:44:24.486 A:middle
let's talk a little
bit about backup

00:44:24.486 --> 00:44:25.586 A:middle
and migration There
isn't have much

00:44:25.586 --> 00:44:28.716 A:middle
to stay I told you keychains are
files If you backup your files

00:44:28.716 --> 00:44:33.066 A:middle
and restore them,
everything will be fine

00:44:33.286 --> 00:44:35.996 A:middle
And if you're migrating accounts
using Migration Assistant,

00:44:35.996 --> 00:44:40.126 A:middle
it will migrate your keychains
Everything's fine Hardly a

00:44:40.126 --> 00:44:45.186 A:middle
problem actually If you happen
to be writing system daemons,

00:44:46.546 --> 00:44:50.016 A:middle
I've already alluded to
that, system daemons are not

00:44:50.546 --> 00:44:53.866 A:middle
in graphic sessions They
can't put up security dialogs

00:44:54.476 --> 00:44:59.866 A:middle
So you are in that particular
hole The system keychain is your

00:44:59.866 --> 00:45:02.226 A:middle
default keychain If you
are in a system daemon,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:59.866 --> 00:45:02.226 A:middle
default keychain If you
are in a system daemon,

00:45:02.226 --> 00:45:05.726 A:middle
you can store secrets in
the keychain, but it will go

00:45:05.726 --> 00:45:09.116 A:middle
into the system keychain The
system keychain is writable

00:45:09.116 --> 00:45:12.886 A:middle
by root only; so in order to
write to the system keychain,

00:45:12.886 --> 00:45:16.286 A:middle
in order to create or modify
keychain items, you need to run

00:45:16.286 --> 00:45:21.466 A:middle
as root Retrieving is fine
no matter what UID you are

00:45:22.206 --> 00:45:27.076 A:middle
So as a daemon, your keychain
is the system keychain

00:45:27.806 --> 00:45:32.156 A:middle
And you have no access
without a lot of back flipping

00:45:32.476 --> 00:45:35.346 A:middle
to the user's keychain because
if you're a system daemon,

00:45:35.346 --> 00:45:37.836 A:middle
you don't have a user
For all you know,

00:45:37.836 --> 00:45:40.146 A:middle
there might be four users logged
into the system right now,

00:45:40.146 --> 00:45:44.776 A:middle
or none at all; so if you're
searching for keychain items

00:45:44.776 --> 00:45:46.446 A:middle
in a system daemon, anything

00:45:46.446 --> 00:45:49.046 A:middle
that the user created
the normal way inside

00:45:49.046 --> 00:45:53.336 A:middle
of that normal login keychain,
you just can't see So the not

00:45:53.336 --> 00:45:56.556 A:middle
so bad news on OS X is that
there is a tool that allows

00:45:56.556 --> 00:45:59.286 A:middle
to you to work with keychain
files It's called the

00:45:59.286 --> 00:46:00.186 A:middle
"security command."

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:59.286 --> 00:46:00.186 A:middle
"security command."

00:46:00.916 --> 00:46:06.996 A:middle
It's in usr/bin, and because the
default sharing rule on OS X is,

00:46:06.996 --> 00:46:08.776 A:middle
if you can see it,
you can fondle it,

00:46:08.776 --> 00:46:10.306 A:middle
you just can't get the value

00:46:10.306 --> 00:46:14.896 A:middle
out without passing the ACL test
The security command can show

00:46:14.896 --> 00:46:17.076 A:middle
you all of the items
in the user's keychain,

00:46:17.076 --> 00:46:19.456 A:middle
or for that matter, all of the
items in the system keychain,

00:46:20.356 --> 00:46:21.946 A:middle
and it will, if you pass it,

00:46:22.086 --> 00:46:25.196 A:middle
the right convoluted options
will actually tell you what

00:46:25.196 --> 00:46:29.886 A:middle
access control lists it has and
what its attributes are In fact,

00:46:29.886 --> 00:46:31.546 A:middle
you can use the keychain --

00:46:32.106 --> 00:46:36.146 A:middle
the security command to
essentially preflight APIs

00:46:36.146 --> 00:46:39.416 A:middle
from the command line if you're
so inclined If you're wondering

00:46:39.416 --> 00:46:42.256 A:middle
if a particular combination
of attributes will work

00:46:42.256 --> 00:46:47.396 A:middle
to find an item, there
is a security subcommand

00:46:47.736 --> 00:46:50.756 A:middle
that just searches
the keychain for items

00:46:50.756 --> 00:46:51.906 A:middle
with particular attributes

00:46:52.536 --> 00:46:55.896 A:middle
So it's pretty handy There's
security dump keychain

00:46:55.896 --> 00:46:59.986 A:middle
with dumps out the entire
keychain for your introspection

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:00.116 --> 00:47:02.796 A:middle
Of course, it was still not
give you the actual values

00:47:02.796 --> 00:47:08.536 A:middle
of the secrets unless you have
access to them So they're --

00:47:09.846 --> 00:47:13.116 A:middle
just to clarify: The security
command has no special magic

00:47:13.806 --> 00:47:17.146 A:middle
features It's just
a normal API client

00:47:17.146 --> 00:47:20.626 A:middle
for the keychain APIs
It will not do anything

00:47:20.696 --> 00:47:26.216 A:middle
that the normal keychain
APIs cannot do But on OS X,

00:47:26.216 --> 00:47:32.796 A:middle
that's actually a heck of a lot
All right Welcome back IOS crowd

00:47:32.796 --> 00:47:35.046 A:middle
We're now talking about
both systems again

00:47:36.386 --> 00:47:38.866 A:middle
And this is the section
where I talk about stuff

00:47:38.866 --> 00:47:41.606 A:middle
that just didn't make
it anywhere earlier

00:47:41.606 --> 00:47:47.626 A:middle
in the presentation I've
talked about secrets so far --

00:47:47.976 --> 00:47:51.506 A:middle
accounts, passwords, and
PINS, you know, all that stuff

00:47:52.336 --> 00:47:56.366 A:middle
that you generally retrieve from
a keychain in order to use it

00:47:56.686 --> 00:48:01.016 A:middle
as the text or data value
that it is for something,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:56.686 --> 00:48:01.016 A:middle
as the text or data value
that it is for something,

00:48:01.776 --> 00:48:04.056 A:middle
authenticating, passing
it off to a service,

00:48:04.056 --> 00:48:10.206 A:middle
whatever The keychain actually
can store a lot of other things,

00:48:10.206 --> 00:48:13.796 A:middle
too I told you it's a
database, and it really is,

00:48:13.796 --> 00:48:18.906 A:middle
and in particular, it has
database schemas And one

00:48:18.906 --> 00:48:23.496 A:middle
of the things that you can store
in the keychain is certificates

00:48:23.496 --> 00:48:29.976 A:middle
and cryptographic keys This
presentation focuses on how

00:48:29.976 --> 00:48:35.856 A:middle
to simply work with passwords,
but I should at least mention,

00:48:36.356 --> 00:48:40.176 A:middle
if you're doing things like
client-side SSL authentication,

00:48:40.976 --> 00:48:45.156 A:middle
what will happen is that your
cryptographic identity, the key

00:48:45.156 --> 00:48:46.866 A:middle
and the certificate
that you're presenting

00:48:46.866 --> 00:48:52.616 A:middle
to the web server will end
up stored in a keychain,

00:48:52.616 --> 00:48:55.096 A:middle
and the CF network
APIs will essentially,

00:48:55.166 --> 00:48:57.806 A:middle
if everything works well,
automatically fetch them

00:48:57.806 --> 00:49:00.926 A:middle
out of there and use them Keys

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:57.806 --> 00:49:00.926 A:middle
out of there and use them Keys

00:49:00.926 --> 00:49:03.226 A:middle
and keychains are actually
handled by reference,

00:49:03.716 --> 00:49:05.376 A:middle
which is a really
cool feature It means

00:49:05.606 --> 00:49:10.136 A:middle
that unlike certain other
legacy APIs, you don't ever have

00:49:10.136 --> 00:49:13.626 A:middle
to have the keys in your
address space And so

00:49:13.626 --> 00:49:18.206 A:middle
if you get compromised all, is
not lost That's good So keep

00:49:18.206 --> 00:49:21.626 A:middle
in mind there is an API suite
called SecKey for dealing

00:49:21.626 --> 00:49:24.866 A:middle
with cryptographic keys, and
those are typically stored

00:49:24.866 --> 00:49:28.806 A:middle
in keychains, works on iOS

00:49:28.806 --> 00:49:32.476 A:middle
and OS X There is a
SecCertificate API for dealing

00:49:32.476 --> 00:49:35.806 A:middle
with certificates; mostly for
finding them, but there's also

00:49:35.806 --> 00:49:38.756 A:middle
and API for creating them
And there is SecIdentity

00:49:38.756 --> 00:49:41.686 A:middle
which is a little bit odd
because it's literally a pair

00:49:42.146 --> 00:49:48.606 A:middle
of private key and a certificate
SecIdentity objects aren't

00:49:48.606 --> 00:49:52.526 A:middle
actually anything physical They
are a pair of a certificate

00:49:52.526 --> 00:49:54.846 A:middle
and a private key that
were found in your keychain

00:49:54.846 --> 00:49:57.816 A:middle
so that belong together The
system knows how they fit

00:49:57.816 --> 00:49:59.636 A:middle
together This is what you use

00:49:59.666 --> 00:50:02.666 A:middle
for cryptographic
authentication What --

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:49:59.666 --> 00:50:02.666 A:middle
for cryptographic
authentication What --

00:50:05.256 --> 00:50:13.516 A:middle
yeah Okay All right
Well, one last thing:

00:50:13.846 --> 00:50:18.726 A:middle
iCloud keychain It's been
announced so I can tell you

00:50:18.726 --> 00:50:26.346 A:middle
about it Once upon a time there
was a way to synchronize secrets

00:50:26.346 --> 00:50:30.366 A:middle
in keychains and that
feature disappeared awhile ago

00:50:30.366 --> 00:50:37.246 A:middle
because times change So now
we have something better The

00:50:37.486 --> 00:50:41.046 A:middle
SecItem APIs are our simple
APIs, the "straightforward,

00:50:41.046 --> 00:50:43.026 A:middle
just do this if you
can get away with it,

00:50:43.376 --> 00:50:44.616 A:middle
don't get any more complicated

00:50:44.616 --> 00:50:48.376 A:middle
if you can avoid it" APIs You
can add one more key to them --

00:50:48.636 --> 00:50:55.546 A:middle
this one And it starts sharing
your items between OS X devices

00:50:55.546 --> 00:51:05.296 A:middle
and iOS devices for that user
That's all you have to do.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:55.546 --> 00:51:05.296 A:middle
and iOS devices for that user
That's all you have to do.

00:51:05.296 --> 00:51:05.646 A:middle
[ Pause ]

00:51:05.646 --> 00:51:05.996 A:middle
[ Applause ]

00:51:05.996 --> 00:51:13.766 A:middle
We try to make things
simple So this works on iOS,

00:51:13.766 --> 00:51:21.886 A:middle
it works on OS X; of course,
iOS 7, OS X 10.9 You need to add

00:51:22.266 --> 00:51:26.236 A:middle
that attribute to all
of your API calls,

00:51:26.636 --> 00:51:30.526 A:middle
not just the creation call And
as it says on the label usually,

00:51:30.526 --> 00:51:31.656 A:middle
"some restrictions apply";

00:51:32.176 --> 00:51:36.296 A:middle
in particular the lower-level
APIs I told you about on OS X,

00:51:36.686 --> 00:51:41.666 A:middle
the SecKeychain APIs, they don't
play nice with iCloud keychain

00:51:42.166 --> 00:51:46.206 A:middle
So if you are planning on using
iCloud keychain, you really,

00:51:46.206 --> 00:51:47.076 A:middle
really need to stick

00:51:47.076 --> 00:51:52.196 A:middle
to the high-level APIs Just call
SecItem, add that attribute,

00:51:52.696 --> 00:51:55.886 A:middle
and keep it simple It does work

00:51:55.886 --> 00:52:03.186 A:middle
with the application sharing
feature So to sum it all up:

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:51:55.886 --> 00:52:03.186 A:middle
with the application sharing
feature So to sum it all up:

00:52:04.196 --> 00:52:07.546 A:middle
Use the keychain APIs to
store your secrets It's better

00:52:07.546 --> 00:52:09.126 A:middle
for you It's better for
the user It's better

00:52:09.126 --> 00:52:14.756 A:middle
for the environment Don't do
your own secret storage It's

00:52:15.156 --> 00:52:18.006 A:middle
going to end up badly,
if not now, then later,

00:52:18.786 --> 00:52:22.916 A:middle
because this is hard and you're
doing enough hard coding already

00:52:24.676 --> 00:52:29.656 A:middle
Keep your APIs as simple as
possible, and that's not just

00:52:29.756 --> 00:52:32.296 A:middle
because complicated
breeds more bugs,

00:52:32.756 --> 00:52:35.506 A:middle
but also because complicated
is a really bad thing

00:52:35.506 --> 00:52:39.976 A:middle
when you're doing security The
more complicated you make your

00:52:40.326 --> 00:52:43.516 A:middle
secret storage setup,
the more likely it is

00:52:43.516 --> 00:52:45.876 A:middle
that some combination
of circumstances

00:52:45.876 --> 00:52:49.036 A:middle
that you didn't even think about
it, is going to lead to a hole

00:52:49.036 --> 00:52:54.906 A:middle
in your security strategy
If you can at all,

00:52:55.326 --> 00:52:58.816 A:middle
stick with this SecItem APIs
Stick with the memory workflows

00:52:58.816 --> 00:53:01.456 A:middle
if that's what you're
doing Try not

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:58.816 --> 00:53:01.456 A:middle
if that's what you're
doing Try not

00:53:01.456 --> 00:53:04.286 A:middle
to manipulate ACLs unless
you absolutely have to,

00:53:04.286 --> 00:53:09.156 A:middle
and if you do, stick with the
sample code for that on OS X,

00:53:09.386 --> 00:53:11.956 A:middle
and you'll be living
happily ever

00:53:11.956 --> 00:53:17.606 A:middle
after All right Paul
Danbold, the gentleman here,

00:53:18.116 --> 00:53:21.856 A:middle
is usually lonely and bored,
and he loves to get e-mails;

00:53:22.856 --> 00:53:25.396 A:middle
the more the better
He's the evangelist,

00:53:25.396 --> 00:53:28.346 A:middle
and he has gotten very
good at telling you

00:53:28.346 --> 00:53:34.586 A:middle
who should be talking to you The
keychain APIs are public APIs

00:53:34.586 --> 00:53:35.466 A:middle
They're documented

00:53:35.576 --> 00:53:39.676 A:middle
on the developer website There
is plenty of documentation to go

00:53:39.676 --> 00:53:42.866 A:middle
around Start with this URL if
you haven't ever looked at it,

00:53:42.866 --> 00:53:45.156 A:middle
and there will be
cross-references leading you

00:53:45.156 --> 00:53:50.136 A:middle
elsewhere If you are
wondering about storing keys

00:53:50.136 --> 00:53:55.076 A:middle
and certificates in keychains,
there is a technical Q&A, 1745,

00:53:55.076 --> 00:53:59.096 A:middle
that focuses on that and
should serve to get you started

00:53:59.146 --> 00:54:05.006 A:middle
with how to set this all up If
you're just wondering how all

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:53:59.146 --> 00:54:05.006 A:middle
with how to set this all up If
you're just wondering how all

00:54:05.006 --> 00:54:07.046 A:middle
of that cryptographic
protection thing works

00:54:07.046 --> 00:54:09.356 A:middle
and why you should trust
us, there's a white paper

00:54:09.636 --> 00:54:13.236 A:middle
that describes how it works
under the hood You don't need

00:54:13.236 --> 00:54:16.986 A:middle
to read that in order to use the
keychain, but if you're curious

00:54:17.316 --> 00:54:20.356 A:middle
And if you have any questions
start asking each other

00:54:20.356 --> 00:54:23.076 A:middle
in the developer forums,
and then we'll take it

00:54:23.076 --> 00:54:25.776 A:middle
from there And that's it.

00:54:26.276 --> 00:54:37.880 A:middle
[ Applause ]