


PIV specification is slightly easier to follow and it turns out smart card logon requires a tiny subset of specified functionality. Why PIV? In fairness it is one of two options: support for PIV and GIDS standards is built into the OS starting with Windows 7. More over there is a discovery process to automatically recognize such cards as soon as they are introduced to the system.

Write a minimal PIV application for the eSE.Putting together all of this, we can implement Windows smart card logon with an Android phone: New applications can be written in Javacard and installed, as long as card manager keys are known. The eSE is a fully programmable environment.When the NFC controller is put into “card emulation mode” and tapped against a contactless reader attached to a PC, the phone looks just like a traditional smart card to the PC operating system.Many recent Android devices have an NFC controller and embedded secure element (eSE) which is comparable to the hardware inside ordinary smart cards.Smart card logon for Kerberos with PKINIT is already built into Windows.Here we consider a different approach where the phone is used as primary credential, replacing a standard smart card in conjunction with a short user PIN. Restricting our attention to PCs running Windows on one side and Android devices on the other, it turns out the bulk of the machinery required for implementing this is already present. Quick recap of these raw ingredients from previous posts: In addition these ad hoc schemes are not compatible with how authentication works for typical operating systems– for example in an enterprise environment, that means Kerberos. There are different ways to interpret the notion of “logging into your computer PC using a phone.” While it is increasingly common to see phones provide second-factor for login to websites (by sending SMS challenges or using installed apps to generate one-time passcodes) users still have.
