Background
The Identity and Access Management team are looking to urgently launch a new Virtual Smartcard that takes new components from an organisation called Entrust and builds them into the NHSD IA client and CIS software.
The launch has been accelerated to support the COVID-19 response. This new Virtual Smartcard technology will be launched late June / early July with a controlled roll out into targeted care environments. We are targeting this timescale to also support advanced signature for prescription signing which has significant advantages for the GP Suppliers. We therefore would also like to prove this functionality in parallel with the specific work outlined below.
The Virtual Smartcard is presented to the system through an application on the mobile device (Apple or Android only) which uses Bluetooth connectivity to present the Virtual Smartcard to the operating system via an additional Bluetooth driver that is supplied by Entrust. This presents the Virtual Smartcard to the operating system as if it was a physically connected Smartcard. The use of Bluetooth allows a level of proximity-based authentication and disconnection as the Virtual Smartcard is presented to the system and removed from the system as the user comes in and out of range (pin numbers are still required to perform authentication).
The Virtual Smartcard is a PIV compliant Smartcard and adheres to the NIST Standards (SP800-73-4). Unlike the Series 8 Smartcard, there is no compatibility support for the legacy interfaces that suppliers have leveraged previously to interact with the PIV compliant Smartcards.
We believe that many of the GP Systems are interacting with the Smartcards via the Oasis PKCS#11 standard interface using the Gemalto gclib.dll. Additionally it may be that other approaches to communicate with the Smartcards are being employed, but they are likely to be using specialized calls that will not support the PIV Smartcard architecture.
This means that the GP Systems can only interact with legacy Smartcards that are either Gemalto Cards ( Series 4 through 6) or Gemalto Compatible (Series 8). This means that any Smartcard that does not adhere to the aforementioned criteria will not successfully work inside of these applications. Therefore, the introduction of a new Smartcard, whether it is virtual or not, will require change. It should be noted that future physical Smartcards that are to be introduced into the NHS estate will be PIV and therefore these same changes are required to be made.
Additionally, legacy Identity Agents will not support PIV Smartcards be they physical or virtual. For instance the legacy B.T I.A can only process Smartcards that are either Gemalto Smartcards (Series 4 through 6) or Gemalto Compatible (Series 8). However, the NHS Digital Identity Agent does support alternate Smartcards and is not tightly coupled to the Gemalto middleware or PKCS#11 libraries. The pending NHS Digital Identity Agent release also provides Virtual Smartcard user information which is not available in earlier versions.
In the long term (2 years+) we expect old Smartcards (Gemalto) to be deprecated from the estate along with old versions of IA Agent. This work will support that deprecation strategy.
Outline Plan
We have the technical resource available to work closely with the suppliers in a collaborative way to help them identify, code and prove the issues are fixed before allowing the suppliers to complete their assurance cycles. During this collaborative working we’d also look to prove out that the EPS advanced signature capability will work with the GP system suppliers so that when ready to launch for primary care is supports the main use cases of authentication and signing of a prescription.
These resources can be made available immediately to support suppliers.
We have already had success with one supplier in this space who has moved to the new required interface so we know that this approach works.
Timescale for completion: ASAP
Summary of Change
We’d like the GP Suppliers to remove the reliance on the Gemalto interfaces and DLLs in favour of using the generic interfaces that allow for the support of all Smartcard types. This will also help mitigate medium term roadmap challenges. We believe that this will also resolve issues we’ve seen in the INT environment when initially testing the GP Supplier systems with the new Entrust Virtual Smartcard. Two examples outlined below:
You can authenticate to one system. If the session locks, entering the PIN to unlock does not work. A temporary workaround is to temporarily disconnect the connection (mimicking physical Smartcard removal) and re-connect. This causes the session to automatically unlock and does not require the PIN entry again.
You can authenticate to another system, if the session locks and you are asked to enter a PIN to unlock, it doesn't matter what you do (disconnect /reconnect VSC, Enter PIN, etc.) it doesn't unlock and instead throws an error.
These issues are likely caused by the application expecting that the target Smartcard is Gemalto or Gemalto compatible when it is not and therefore the commands are failing and causing an error
Full Specification
TBC
Assurance Approach
TBC