Beneath, Between & Behind - A Smart Card Reality
Beneath the noble birth
Between the proudest words
Behind the beauty, cracks appear
Please don’t throw the baby out with the bathwater.
I’ve always hated this saying, but there is a point to it, and this point resonates with me when it comes to upping the game of human identity-based authentication. We in the public sector have spent millions of dollars and dozens of years putting a pretty good system in place to deal with this.
Pretty good...but not great and not without its holes - some small, some gaping. We’ve also been lurching back and forth between “smart cards are dead!” & “smart cards are with us forever!”. The truth, as it always is, is somewhere in between.
We spend a good amount of time talking about quick wins to get started (or maybe restarted?). Or, at least, recommitted to closing the gaps that exist and doing it in a way that has an eye toward a longer, more complete journey and doesn’t break the proverbial piggy bank.
But from an enterprise perspective, we have to keep going back to the investments we’ve made and find a way to leverage them.
We’ve tried to do this with a derived credential with mixed results. While it looks good on paper, you lose something in the translation - you lose one of your factors. It would be a stretch to call PIV-D (Derived Personal Identity Verification) multi-factor authentication.
So you would still need something else. And while it’s great in a mobile context and will be even greater once all endpoint platforms have on-board TPMs (Trusted Platform Module) or a secure hardware-based element with which to store the credential, it’s still not strong enough. It doesn’t mirror the strength of...the card.
Which is why we want to build in support for card-based proofing for enrollment. This leverages the years-long investment in public key infrastructure (PKI) and “the card” to prove identity and device ownership in order to provision a simpler, more widely-accepted authenticator.
These authenticators can be one or many and can be provisioned and utilized based on risk as outlined in NIST’s SP-800-63-3 guidance. For example, you could authenticate with a PIV or CAC (Common Access Card) and provision a Yubikey for AAL Level 3, AND provision a Duo Push token for AAL Level 2 access.
It’s important to note that since NIST was smart and separated the enrollment/provisioning from usage, this “derived authenticator” should satisfy, depending on workflow, NIST SP-800-63-3 IAL Level 3. We really are moving more toward a “risk-based” model, which will only help us and is really the right security approach.
The technology world is moving fast. This pace is creating heartburn and fire drills in private enterprise, and public sector enterprise is really no different here. By leveraging existing infrastructure and existing investment, we can find a way to save $$$ and deliver a superior user experience while still meeting the “laws of the land.”
These are exciting times and we ain’t even done yet.