(gentle music)
-: So my name is Todd Johnson.
I work for the Bureau of the Fiscal Service.
Specifically, I work
in Information and Security Services,
with the...
Identity, Credential,
and Access Management Division.
Or what we call the I-Cam Division.
So, today we're obviously here
to learn a little,
learn a little bit
about PIV cards.
And this case for today,
what we're covering in the objectives
is what is a PIV credential?
How can I use it
to access business applications
within the Department of the Treasury?
And what are some of the problems
that can occur?
So, throughout the course
of this presentation
it's pretty light on graphics.
And what I'd really like
is if you have any feedback whatsoever,
or if you're having problems
within your agencies,
please feel free
to speak up at anytime.
If you have any questions whatsoever
about the credential,
or the ecosystem of credentials,
then please again interrupt me.
I have no problem with it.
I like interactive dialogue.
So, a PIV card.
This content is shamelessly taken
from a website, where the reference
is in the very last slide.
So, you can read additional details
on what I'm covering here.
This is just high level overview
of the credential itself.
But, to read from the slide verbatim.
"A personal identity verification credential
"is a US federal government-wide credential
"used to access federally controlled
"facilities, and information systems,
"at the appropriate security level."
So everybody that's here today,
how many people actually have
a PIV credential?
Pretty much everybody here.
Great, so have you noticed
whenever you came
into the facility today,
that you were able
to present your card,
and you didn't have
to go through the metal detector,
because we're in a public facility?
Audience: No.
-: Oh wow, so if you actually present
your PIV credential at the door,
the guards will allow
you to bypass the metal detectors.
(audience speaking faintly)
Really?
(audience speaking faintly)
Is it only Treasury employees?
Well, isn't that weird?
Man In Audience: Treasury and Commerce.
-: Treasury and Commerce?
(man In Audience speaking faintly)
And perhaps,
I did see DHS around as well.
So, next slide.
PIV credentials have certificates
and key pairs, they have PIN numbers,
biometrics like your fingerprints,
your picture is on it as well.
It's also electronically
on the credential.
When you put all of this together
as an overall credential,
it provides us the capability
to perform multi-factor authentication
for our networks, applications
and ultimately our facilities.
So in a lot of our facilities
you'll see, whenever you're walking
in the door, you hover your badge
over a reader.
Now it's just reading an indicator
off of that credential,
there's really not much
that's going on.
In some cases, such as here,
you present your card
and they see your facial information.
So, it's like a driver's license.
So with this, the PIV credentials
actually have two primary features.
You have the physical elements
of the card.
Much like, you know,
the standard identity documents,
like a driver's license.
Most folks, I think, in
almost all states now,
you have the REAL ID act
that's in place.
So, you can't use your driver's license
unless the state complies
with the REAL ID act.
So, there are certain special areas,
of the card, where information
is required to be placed.
So, you'll see the picture
information about your name,
your agency affiliation.
Do we have any DoD employees
in the room today?
Awesome, well with your credential,
it's no different than just a PIV card.
I know it's referred to as CAC,
or the Common Access Card.
For the folks that are actually here
in the room,
have you updated your credential
over the past year?
Awesome so, for those
of you that haven't,
I'd really like to ask
you for a favor.
And please, at your earliest convenience,
please look at the website, https://www.cac.mil.
You'll notice that there was an update,
or in the news section,
in the right-hand side
of the website, there's news
about modernizing CAC.
And one of the things that is occurring,
with the credentials, is they are trying
to make it look a lot more
like a PIV credential electronically.
And I wanna cover this in a second.
But whenever you're interacting
with our applications,
for the Treasury and applications
that you interact with,
you're interacting with this
by way of your electronic portion
of your credential.
So, for the purposes of the card,
the card can electronically be validated,
because there is certain electronic
information that can be pulled
off of that card,
from a contactless perspective.
That's why, whenever you walk
in a door, and you hover
your card over a reader,
it's able to read some information
off of your card.
And that information is digitally signed.
So, that information is very hard
to forge, if not impossible.
There's also something
on there called,
a Card Authentication Certificate.
I would assume that
as people have been
using your credentials,
at each of your agencies,
have you ever heard the term, certificate?
That's more of a reference
to something called,
Public Key Infrastructure, or PKI.
So, within this ecosystem
of credentials that we have,
there are quite a few entities
that have the capability
to issue certificates
from the overall PKI,
that supports PIV credentials.
There's approximately about 180
of these issuing CAs,
that are actively issuing
these credentials today.
From DoD, who issues
for all federal civilian.
And Treasury, we support all of Treasury,
DHS, NASA, Social Security Administration
and Veterans Affairs.
Are any of those agency customers
in the room today?
Well, we assist you
with the production of your PIV card.
So if you have any additional questions
in the future, please feel free
to reach out to me, any time,
because I also work for you,
at those different agencies.
So, let's get to the meat of this.
The card itself,
what authenticates you
is clearly your picture.
Whenever you walk in the door,
someone can see your picture.
There's a biometric identity
information as well,
such as fingerprints and iris.
So whenever you had PIV credential
activated for the very first time,
you set a PIN number.
And you had to use your fingerprint
whenever you originally enrolled,
you used that fingerprint
to identify that it truly is you.
And of course, the activator,
they can see your picture.
So there's a lot of care placed
into the issuance of these credentials
to ensure that we're issuing them
to the correct individuals,
and identifying them appropriately.
The primary authenticator
that we interact with
is what's called,
the PIV Authentication Certificate.
Now, there are some other certificates
that are on the card.
And those are only used
for some highly specialized applications,
we have in Fiscal Service.
Does anybody have access
to the Treasury Secure Payment System?
So either as a data entry officer,
or a certifying officer,
it's a little bit more advanced.
Because we're not using a web browser.
I'm not covering a lot
of the details
in this presentation today.
But of those agencies
that are accessing SPS,
how many are you using
their PIV credentials?
How many are not using their PIV cards?
So, with some of the folks
that are in the room
that are not thus far,
would you mind speaking up?
Which agencies are you?
-: [Woman In Audience] Indian Health Service.
Indian Health Service.
(woman speaking faintly)
HUD.
And I know that we don't have access
for our DoD partners yet,
for Secure Payment System.
That is something that's coming soon.
So payment management
is on a pretty aggressive schedule,
to start converting agencies across.
We have had some challenges,
as we have been performing that migration.
I'll speak to that here
in just a moment,
in a future slide.
But I will not be going
into explicit detail about SPS,
but some of the technology challenges
we've actually encountered.
So when interacting with our applications,
there's really two primary components
that we work with.
The card itself obviously,
that has your certificate on it.
And then a PIN number.
So this PIN number is specific
to your card.
We can't really tell you what
this PIN number is.
You assign that PIN number,
whenever you activate your card.
So whenever you're inputting
the information into your computer,
whenever you enter your PIN,
we will never see that information.
It actually goes to your card,
and unlocks that PIV authentication
certificate, to where it can be used
through your computer,
and then your browser.
So as an example, I've included
a couple of screens.
And I'm going through
these slides pretty quick,
so I really hope some folks
are really going to have
a lot of questions for me.
In this case, this is an application
that is in our TWAI environment.
You may have heard
as you've been going
through some of these
different presentations today.
We have the
Treasury Web Application Infrastructure.
We also have Fiscal IT.
We have different applications
that are going
into cloud environments, as well.
So we enable these applications
through a set of Single-Sign On systems,
that we are consolidating.
At the moment,
you will see this screen
whenever you need
to try and authenticate
with your PIV card.
You log-in by selecting, PKI Certificate.
It's the same,
where you may have additional options,
such as USER ID and password.
But again, you would select PKI Certificate.
This is the Treasury Single-Sign On page.
Most Treasury employees
are familiar with this,
for access to a lot
of our internal applications.
Such as, Concur for travel.
HR Connect for your employee resources.
While it says PIV,
this is also inclusive
of PIV-I credentials,
for our Federal Reserve Bank partners.
As well as,
for DoD personnel in your CAC.
We just refer
to the technology, as PIV.
Once you've selected to authenticate,
using your PIV card,
you may end up receiving
a pop up dialogue that forces
you to select a certificate.
And so, as I've mentioned before,
there are a couple of different
certificates on the card.
In fact, there's four.
There's the card authentication
certificate that you really
don't use for yourself.
It doesn't even require
a PIN to activate it.
You can just hold that card
over a reader contactlessly,
and cryptography will occur
between the actual card itself,
and the terminal,
from a physical access control perspective.
That technology is only
to identify the card, not you.
So that leaves three other certificates,
on a PIV credential,
that we generally interact with.
With web browser based authentications,
the primary method
of accessing our applications is using
this authentication certificate.
Whenever your card
is put into the PC,
there's some specialized software
that's on that PC
that allows your smart card to be read.
Because it, in and of itself,
is its own independent computer.
So, we refer to that as smart card middleware.
What you will see here
in a few moments,
is PIN dialogue for ActivClient.
But there's other smart card middleware
such as Xtec, AuthentX ware.
Or, Microsoft has a native capability,
or what's called a Windows minidriver.
And this allows the web browser software
to communicate with the card,
to get the listing of certificates.
So if you receive a prompt,
that is asking you for a certificate,
we're looking for the authentication certificate.
Now, that's really easy to confuse.
And I will be addressing
this in a future slide.
So, do we have any questions
thus far, before I keep moving on?
Yes sir.
(man speaking faintly)
For federal agency, as well
as our Fiscal and financial agents,
we're already working very hard
to honor PIV credentials
from every single federal agency.
We also work with the Federal Reserve Banks
and require them
to obtain PIV-I credentials.
Those are interoperable credentials.
The only difference
is they don't require a background
investigation on issuing them the card.
We handle that a little bit differently.
Man In Audience: For Single-Sign On,
we no longer are able
to use the PIN password.
Over a period of time,
it's really dependent
upon the application.
So, this is where we get
into the details of each
of the individual application.
Do you have an application,
you're specifically curious about?
Man In Audience: For Single-Sign On.
-: Just for a Single-Sign On?
Man In Audience: Correct,
Treasury Single-Sign On.
-: Well, Treasury Single-Sign On
supports a lot of applications.
Man In Audience: Exactly.
-: Right so,
we prefer
that federal employees
that have a PIV credential
use their PIV credential,
in order to authenticate
through Treasury Single-Sign On.
If you do have a USER ID and password,
that is something
that we are trying
to phase out over time.
Man In Audience: But there's no drop
dead day at this time?
-: It depends on the application, specifically.
Man In Audience: The Single-Sign On.
-: Well, Single-Sign On is really
a platform that integrates
multiple authentication providers--
Man In Audience: I understand
that's how you get into the system.
-: Okay.
Man In Audience: So, nevermind.
-: No, please feel free
to come up and we'll talk
about it more in detail,
after the presentation.
So for Treasury Single-Sign On,
and I can step off.
We'll talk about
that for a moment.
So Treasury Single-Sign On
supports multiple applications,
in multiple environments.
You could be accessing
the IPPG invoicing
to
TreasuryDirect.
Some of our commercial based applications,
or our retail based applications.
And so, we have policies
for each individual application
that have requirements on whether,
a password and USER ID is appropriate.
Or we may force,
for a given application,
the required use of a PIV credential.
So that's a reason why understanding
the application is specific.
Because the Single-Sign On
system trusts multiple,
or provides services,
to multiple applications,
at multiple service levels.
So, to get into a little bit
of the technical detail on that,
we have a standard
that we're migrating to.
NIST published, "Special Publication 800-63-3."
And that combined with
OMBM1917, which was just released.
Really focuses on the way
we do our categorization of risk
for each of our applications.
So you may have heard
of terms like, assurance levels,
in the past.
There were four assurance levels
that we dealt with.
LoA1 through LoA4.
That has changed.
And now they've split that apart
into an identity assurance level,
and an authentication assurance level.
So a PIV credential, for example,
is identity assurance level 3,
the highest you can go.
And authentication assurance level 3.
So as we're working
with each of the applications,
that are integrated
with Treasury Single-Sign On,
we obtained the requirements
from the application.
And that is what places the requirements
through Treasury Single-Sign On,
that affects your experience.
So we may have
applications that require
that higher level of assurance,
where other applications
may not have that same requirement.
So back to this PIN prompt,
or the certificate selection dialogue.
Again, it's quite important
that you select the authentication certificate
of your PIV card.
This is a separate dialogue
that you may experience,
through Google Chrome.
If you've ever taken a look at,
or been curious about web browsers
that are used across the federal government,
a really nice
website is https://analytics.usa.gov.
You'll find that a lot of individuals,
that are interacting
with federal IT systems,
or federal websites,
are using Google Chrome.
Approximately 7%, are still
using Microsoft Internet Explorer 11,
which we've noticed this
from a lot of our partner federal agencies.
So, the prior dialogue
is what most customers
will see when using
Microsoft Internet Explorer.
When using Google Chrome,
you'll see a little bit
of a different dialogue.
Now, you'll notice
that you can't find
the authentication certificate,
in this dialogue.
You can look
at the individual certificate information.
And I have a future slide
that will provide a bit
of a reference, or a little bit of help.
So as I've mentioned before,
after you've selected your certificate.
And you select OK.
You'll be prompted
for your PIN number.
This is a PIN number
for your PIV card,
that only your PIV card can understand.
And that will unlock
the use of the card,
so your certificate can be used
to establish a secure session
with Treasury Single-Sign On,
and then thus, the application.
The web browser again,
you may see like additional
certificates for use.
In the example, that I have provided before,
I'm gonna switch back to it.
You'll see this other certificate
that issued from communications server.
It only has a one day lifetime to it.
It's like a one day driver's license.
This is something
that's actually issued
on a daily basis,
from Microsoft Office 365.
The big distinguishing identifier
whenever you're just looking
at the dialogue,
is you see that the issuer
is US government,
for my PIV authentication certificate.
And for the other certificate,
it's just communications server.
So again, depending on the middleware
that you're using
within your organization,
I know a lot
of DoD uses ActivClient.
A lot of customers
of GSA's USAccess
also uses the ActivClient middleware.
Your PIN dialogue may
be a little bit different.
Depending on your agency's policy
you may have up to six tries,
for your PIN number,
before you block your card.
Generally, the smart card middleware
will give you a warning,
if you are entering
the password multiple times.
It'll tell you, generally,
how many retries
you do have left.
In order to look at the specific
information, regarding certificates,
I'm going to show you
on the next slide.
But I am gonna reverse
on the past two slides
to show you the
Internet Explorer dialogue again,
as well as the Chrome dialogue, again.
You'll notice here,
there's a certificate information button.
So you can select
a particular certificate,
and then look
at the certificate details.
For Internet Explorer,
you can select the certificate itself,
and then click here
to view the certificate properties.
This will lead to...
I apologize.
Seeing the actual certificate.
Or, the rendering of a certificate.
This is from a Microsoft perspective.
There are two different elements
that are in here.
And these slides are available
for the conference attendees,
so you can use this
as a visual reference.
But we have help guides
that also try to provide this information.
The key usage, what we refer
to as a key usage extension,
inserts what's called
a digital signature value.
Then there's also the enhanced
key usage extension.
And it will generally,
always assert smart card login.
Because, as agency employees
you're using your PIV credential
to log in into your desktops
on a daily basis.
That's Windows smart card login.
So it's the same authentication certificate
that we're expecting,
in order to
create a secure session with you.
So, some of the basic problems
that we have run into.
You may see this screen
and I understand
that it is not very pretty.
It's an access denied.
Whenever this occurs,
it's more of an entitlements issue.
You're trying to gain access
to the application,
but we have not provisioned
you within the application,
and you're not authorized
to use the application yet.
We do have additional procedures
that are required
for each application,
to perform an enrollment.
Some people may have experienced this.
It's referred to as our CASS utility.
And that's what allows us
to translate the original
User ID/password, based account
that you previously had.
We're able to switch
over to using the certificates
on the PIV card.
And then last but not least,
a problem that has been
plaguing us for a little while,
is Microsoft Internet Explorer 11.
It is supported,
and it will be supported,
for the lifetime, I believe,
of Windows 10.
We are asking our business lines,
as well as other agencies,
that if possible
we should be trying
to migrate to a more
modern web browser.
Microsoft Edge is currently available.
Google Chrome is available,
as an alternative.
Now this error message,
it is a little bit complex.
Because we get into
the encryption that's used to communicate
between your web browser,
and our web servers.
This is referred
to as Transport Layer Security.
We have been migrating
through the various versions
of Transport Layer Security,
to where we're now on TLS 1.2.
We're not offering TLS 1.3, yet.
So, TLS 1.2, is the latest and greatest.
We have discovered
that there are some federal agencies
that do not have TLS 1.2 enabled
on their browsers.
So if you do experience
this particular problem,
reach out to either
your application support desk,
or my contact information
is in these slides.
If there is any questions,
after this presentation
and you don't feel comfortable
speaking in the audience,
you can feel free
to reach out to me anytime,
through my contact information.
And, that brings us to questions.
So, please.
Staff: Hold on, wait for the mic.
-: I feel like everybody's
so far spread out
in the back of the room.
I wanted to get everybody
to come forward, but.
Man In Audience: So, I work for DHS.
And we're a -: Yes, sir.
Man In Audience: shared services provider
for Treasury Forfeiture Fund.
And one of the systems
I currently have access to is DORA.
-: DORA.
DO Remote Access,
right? -: Right.
So I still have my little fob,
that has the six digit random numbers
that goes with a login and password.
And for the last,
18 months or so,
there's been a push of,
"Well, you need to use
"your PIV card."
And the fix from the help desk
at the time was,
"Oh, we'll get you a Treasury PIV card.
"That'll give you the certificates
"so you can access."
So we go through the process.
We get a Treasury PIV card.
-: Really?
-: [Man In Black Shirt] Yes, as a contractor.
Even though we're federal employees
of another agency.
-: And you have a DHS PIV card,
which Treasury issues the certificates
to those cards. -: Yeah.
-: To where they look
exactly like Treasury's.
-: [Man In Black Shirt] Right.
-: We really need to talk.
-: [Man In Black Shirt] I'm a DHS employee,
and apparently a Treasury contractor now.
So anyways.
When we've tried
to work with the help desk,
their fix has been,
"We'll just use Google Chrome."
Well, our agency IT policy,
we're still on Internet Explorer 11.
You know, we're not allowed
to use Google Chrome
on any of our software,
any of our desktops.
I'm guessing, do you
have any ideas
of how to fix said problem?
-: Oh, absolutely.
Which component do you work
for in DHS?
-: [Man In Black Shirt] CBP.
-: CBP?
-: [Man In Black Shirt] Mhhmm.
-: Well again, my contact information
is at the end slide.
I do not have my phone number
in the presentation,
in a lot of cases.
And there is a good reason for that.
I do want people
to send me an email,
because I may ask you
to digitally sign your email
using you PIV card.
I do that for a couple of reasons.
One, it authenticates you.
And I'll honor your signatures.
It doesn't matter
which agency you're coming from.
You know, I can deal
with the administrivia
and tell what's good,
and what's bad.
So I will be asking,
please reach out to me.
Send me an email, digitally sign it.
That way I can see the details
on your credential.
The fact that we issued
the certificates for your credentials,
I can pull up your personal details.
I work with the operations team
on our PKI side.
So I'm more than happy
to assist you.
On the Treasury side,
we'll wanna loop
in Massai Cassa, who is
one of our
folks that's responsible
for logical access control,
within main Treasury.
So again, I work
for the Bureau of the Fiscal Service.
We do provide PKI services
for all of Treasury.
So I know who to go talk
to at least, on the DO side,
so we can work
through this particular issue.
-: [Man In Black Shirt] That would
be very helpful.
Cause my understanding
is it's gone up the chain,
on both sides for both agencies.
-: And that's a bizarre anomaly.
-: [Man In Black Shirt] And it's just gotten
stuck, at that point.
So far, where they've opened tickets
through the Treasury help desk.
And then, never get a phone call.
Two weeks later,
the ticket gets closes.
-: No worries, so I'll also be pulling
in Gladys Garcia, from DHS.
She's our direct customer
for obtaining the PKI services,
from Treasury's Shared Service Provider Program.
-: [Man In Black Shirt] All right, sounds good.
-: Awesome, sounds like a plan.
I saw a hand up over here first,
and then second.
Oh no, that's fine, you got it.
-: [Man with Glasses] I work
for Federal Financing Bank,
which is part of DO.
And there are some applications
that I'm able to use
the PIV card for,
that are Treasury.
And some that have the PIV card option,
but it doesn't seem
that I'm allowed to.
Is there a reason for that?
-: It may be because
of the entitlements,
in the provisioning.
That is something
that is very challenging for us.
Because on the PIV card
the only way that we can interact
with you, or we see your identity,
is by way of that certificate.
And while that certificate,
I showed some screenshots
of the certificate,
and some of the elements
that are in there.
From a personal information perspective
it's quite poor.
It's very hard for us
to even parse an individual's human name
out of it.
So we have to work
off of other identifiers,
like email address.
So we don't automatically
just trust a certificate.
And then, translate that
to someone's identity.
Because we don't wanna
provide access to your information
potentially, or your agency's information,
just to anybody
that has a matching certificate,
that could be issued
from any one of the 180
Certificate Authorities,
that are part of the Federal PKI.
So, the issue is most likely
due to entitlements.
Do you have a specific application example?
Man In Glasses: It's mostly
the financial reporting.
With the FARS program,
I actually have
to use a password,
an ID and password.
But the SPS program, that's--
-: SPS is a little bit different.
I did refer to that before.
It's a little bit advanced,
because not only do we use
that authentication certificate
that tells us who you are,
you also use your digital
signature certificate
to sign and certify the schedule.
And then, we also require
the use of the encryption certificate,
because once we receive
that payment schedule,
and verify you,
we send the detail,
or the receipt back encrypted to you.
So we use more of the certificates
on the card.
Man In Glasses: But, these would be a package,
they're all DO Single-Sign On.
So I need to sign out
with the same ID and password,
of all of these.
But some of them
I can use my PIV card,
and some of them I can't.
But it's still part
of the same family.
-: And so, are these more
DO internal applications as well?
Man In Glasses: These are financial BFS type.
-: Okay, I would ask you,
please reach out to me.
My contact information
is on the very last slide.
And I would like
to try and work
with you to route,
and try and figure out
the exact problems that you're having,
for each specific application.
Man In Glasses: I just thought
it was odd that I could do
it on some, and not on others.
-: No, that's understandable.
We are in a little bit
of transition phase.
Some of our business lines
have been ready
to migrate to PIV.
And they have been doing so
for a few years now.
While others are trying
to work with customer agencies,
because there has been some anomalies
through different agencies.
Not all agencies in the past
had PIV cards in everybody's hands.
And we would try to go out
to each individual agency
seeing, are you ready
to make this conversion yet, or not?
And it's really challenging
if only one or two people,
in a particular agency,
may have a credential.
So, that is why some applications
are ahead of others.
(man in glasses speaking faintly)
-: Right. (laughs)
Man In Glasses: Two access points,
I've gotta use it
to get in to go to work.
-: Certainly.
So, next question please.
-: [Man in Gray Shirt] You've discussed
problems with the PIV card
for logging in.
I'm interested in what problems
you may have
with the PIV card,
in starting a new application,
or a new software.
I'm developing some
for my agency.
And we have utilized PIV access security
for digital signatures.
As well as, access to the program.
But I'm interested
in what other problems
you might've experienced
for a new application.
-: It's really dependent
on the use case.
Most of our applications
are web browser based.
So for those web browser based applications,
the only part of the credential
that we can really leverage
is that authentication certificate.
I've mentioned, or made reference,
to the Secure Payment System, before.
I'm not certain
if you're familiar with SPS.
-: [Man in Gray Shirt] I am,
I utilize it as well.
But, our agency has not been.
Even though we have
that PIV card,
we don't have the access yet
through Treasury to utilize
the PIV card
for the certification process of SPS.
We still use--
-: They're probably safe
in that iKey token,
with SafeNet middleware.
And so it's a little USB token
that plugs in.
It acts as your smart card reader,
and your smart card,
all in one.
We are phasing those out.
They're tied to one
of our older Certificate Authorities.
We refer to it
as a Fiscal Service CA,
that's been in operation, since 2003.
So it is taking us some time,
because that CA
is specifically tied
to our payment management
business line, or SPS.
As well as, International Treasury Services.
And I believe Judgment Fund.
We're really trying
to focus on the migration
to PIV cards.
I made reference to that OMBM1917,
the new identity policy.
And it clearly states
that we have to not
be showing credentials
to other agencies,
but honoring the credentials
that agencies have already issued,
in terms of the PIV card.
-: [Man in Gray Shirt] So you mentioned
utilizing the authentication part.
What about using the digital
signature part as well,
with the new application?
Cause that's what I'm using.
Both certificates for a new
application that we have launched.
-: So, using that
through a web browser
is gonna be probably
your largest challenge.
That's a reason why,
the Secure Payment System
is written in Java.
And we act as the user agent,
or it's the built-in browser,
and we use toolkits
to communicate with the card
through the Microsoft platform
to interact with all three
certificates on the card.
There are quite a few
different ways to skin that cat,
through different programming languages.
I can speak
to the details of that.
I've written a Java API,
and open sourced it.
It's out on GitHub.
That it even allows
you to read a PIV card
with your mobile device,
if you've got an Android cell phone.
So, I'm more than happy
to share that information.
I've been working
with the technology,
or smart cards
in general, since 1997.
-: [Man in Gray Shirt] I'm very
interested in that.
Cause we do
have a mobile app, as well.
And we'd like to utilize
that on the mobile app, as well.
So what you just mentioned,
I need to get
your contact information.
-: It's on the very last slide.
You will have some challenges,
because our current PIV credentials
that we have,
they're not very mobile friendly.
So I've mentioned,
or gave examples,
before you walk into a facility,
hold that card over a reader.
Well, it's using a contactless technology.
Standards wise, it's ISO14443.
Easy way to refer to it,
is Near Field Communications, or NFC.
So every Android mobile device,
as well as Apple mobile device,
does support NFC.
The challenge is
is you can only use
that card authentication certificate,
and the card, as a transaction.
Because there's no way
to enter your PIN number.
You can't do the cryptography
over that communication,
of that contactless interface,
with the current card stock
that we have in circulation.
There is a new card stock
that we are migrating to,
that conforms to NIST
the "Special Publication 800-73-4."
And that's the new card edge interface.
NIST introduced a new technology
to the PIV card,
that allows for that contactless experience.
And you have a pairing code
that you use with your PIV card,
to pair it to the phone.
These cards are much faster.
And they should make things
a little bit more mobile friendly.
But, in my experience,
we don't see a lot
of people using PIV credentials
with mobile devices.
Just because it's really not
the greatest user experience.
Whenever you're doing
contactless, for example,
and you're trying
to sign something,
you have to hold
that PIV credential
to the mobile device multiple times.
If I had a camera
I could almost demonstrate it here.
It's not the best user experience.
It also takes time
to communicate that information
between the card and the reader.
You can put a smart card reader
in the very bottom
of your mobile device.
DoD piloted this
for quite some time using CAC.
We've learned a lot from them.
It's not exactly very easy to use.
So, I think that you do
have some options.
But please, definitely reach out
to me, and I'd be happy
to share information we have.
And also, introduce you
to other folks
that are developing
for PIV credentials.
Yes, ma'am.
-: [Woman in White Top] I wanna
go back to the tokens
that you were talking about,
and you had mentioned Judgment Fund.
I'm actually with Judgment Fund.
So, we had been hearing
about a transition
over to the PIV cards.
I kinda have a two-pronged question.
First off, do you know
when the transition
is slated to be completed?
And I think I've heard,
DoD may be one of the last
ones that will be moving
from these tokens
over to the PIV.
Do you have a timeframe?
Or, do you know
when the last agency
is projected to--
-: I do not.
That is something
that we've been leaving
to each of the individual business areas,
because we have set dates before,
and unfortunately they have slipped.
Due to either technical development
issues of migrating to the cards.
I had mentioned before,
do we have anybody
in here from National Science Foundation,
out of curiosity?
Yes, no, maybe?
Darren Citron is an individual
that I work with over in NSF.
We found a bug
in their smart card middleware.
So, whenever they would try
to authenticate to,
let's say for example IPP,
or try to log in into SPS,
it just didn't work.
SPS it was a little,
it wasn't a bad failure.
Whenever he tried
to log into IPP,
it literally made his browser crash.
As in the browser just disappeared.
So, we have been able
to work that through
that problem with the vendor.
There is a newer version
of their middleware
out that makes you know,
so the PC doesn't crash.
But that hasn't
been deployed everywhere.
Unfortunately, certain components
of the Department of Homeland Security
use that exact same middleware.
I think Customs and Border Protection.
So, you would want to move
to version four
of the Xtec, AuthentX middleware,
if your agency hasn't already.
But we're sharing this information
also with our Shared Service Provider customers.
-: [Woman in White Top] So then,
the second question.
When the token goes away
I've had a couple people
who agencies they'll call
and say, "Hey, look
"we're off, do you want
"my token back?"
Well, I don't want their token.
Is there a protocol
to get rid of the tokens,
send them back,
where do they need to go?
-: That is a really good question.
I think that the token
should be accounted
for and properly destroyed, or recycled.
And we can do
that by way of procedure,
allowing the user to reset
that token themselves.
But I don't think
that we have any kind
of use for it.
It is an accountability issue,
because as we've issued these credentials.
Just like whenever
you issue, your PIV card
is issued to you,
you sign a legal agreement saying,
you know, that you're not going
to disclose that PIV card.
You're not going
to hand it out.
And in fact, it doesn't
even belong to you.
It belongs to the US government.
I'd ask you to follow up
with me through an email.
And we'll find out the details
on the timelines you need.
As well as, procedures
for destroying tokens,
or collecting them.
More questions, please.
Anybody?
Come on, bring the hard questions.
I really hope
that I didn't seem adversarial
earlier, on the question regarding SSO.
I'm really trying to understand.
Does anybody else
have any questions?
Or is this going
to be an amazingly short presentation?
Well, I appreciate
your time today, and coming.
If you...
for some reason
don't wanna reach out
here in the conference.
Or, if you wanna trap
me in the corner,
that's fine as well.
If you'd like to reach
out to me electronically,
my email address is here
on the screen.
There's some really good
additional reading material
that is maintained
by multiple federal agencies,
out on https://www.idmanagement.gov.
Specifically, PIV covers
a lot more details
about the PIV credential.
It's also a very good developer resource.
There's also,
what we refer to as,
the Federal PKI Playbook.
I'd mentioned, that there are over 180
Certificate Authorities that are part
of the Federal PKI.
If you do look
at that FPKI Playbook,
you'll actually see
a graphic representation
of the Federal PKI.
And you'll get an idea
for the number of CAs
that are part of the infrastructure.
There's also, very helpful
announcements regarding the infrastructure,
and the technology.
As well as, announcements
for any changes by any
of the participating affiliates,
within the Federal PKI.
Like whenever they're making changes.
We do make periodic changes
to the CAs, and the infrastructure.
Recently, we did perform re-keys for Treasury,
DHS, NASA, and Social Security Administration,
and Veterans Affairs.
And we have done
that over the past four months.
So you'll notice your certificates
are slightly changing as well,
with their relationship
to the Treasury Root CA.
So, any questions whatsoever,
it doesn't matter
if it's even not related
to a Treasury application,
please feel free to reach out to me.
This is a technology I work
on most of the time.
And with that,
I thank you for your time.
And have a lovely day.
(audience clapping)
Man In Audience: Can you put your contact--
Todd: I am going to put
that up there right now, I apologize.
(audience member speaking faintly)
Yes I did.