Background

Current suppliers’ products adhere to the existing requirement for working with Smartcards on the Windows Platform which is to use the PKCS11 standard, however it inadvertently relies heavily on the vendor proprietary PKCS11 library to communicate with Smartcards as that was the middleware/solution in use at the time.

 As part of the next Smartcard procurement, NHS Digital intend to move to the PIV/CIV Standard which allows implementers to leverage Microsoft’s built-in APIs (available from Windows 7 SP1 and above). The PIV cards won’t have backwards compatibility with existing proprietary middleware libraries in use (e.g. gclib library).

Part of the COVID-19 response accelerated the introduction of the Entrust Virtual Smartcard solution, during assurance of which it became evident that partners who have implemented the PKCS11 DLLs have a number of issues that prevent authentication and signing actions from being performed when using the Entrust Virtual Smartcard.

 In light of a near term ambition to remove the dependency of proprietary PKCS11 DLL a decision has been taken to resolve the issues seen now.

The Entrust Virtual Smartcard launch is a COVID-19 response item and is required to be supported for both authentication and digital signing as soon as possible by the profession.

Outline Plan

NHS Digital 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, NHS Digital would also look to prove out that the EPS advanced signature capability will work with the GP system suppliers in and end to end test so that when ready to launch for Primary Care, it supports the main use cases of authentication and signing of a prescription.

These resources can be made available immediately to support suppliers.

NHS Digital 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

NHS Digital are looking for the GP System suppliers to remove the reliance on the proprietary interfaces and DLLs in favour of using the generic (NHS Digital) interface that allows for the support of all Smartcard types. This will also help mitigate the medium term roadmap challenges. NHS Digital understand that this will also resolve issues we’ve seen in the INT environment when performing exploratory assurance of the GP Supplier systems with the new Entrust Virtual Smartcard. Two examples are outlined below:

1. A User can authenticate to the system. If the session locks, entering the PIN to unlock does not work. A workaround is to temporarily disconnect the connection between the devices smartphone and  (mimicking physical Smartcard removal) re-connect. This causes the session to automatically unlock and does not require the PIN entry again.

1. A User can authenticate to the second system, however, 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. There is no workaround to the issue.

These issues are likely to be caused by the application expecting that the target Smartcard is a specific type or one that is compatible when it is not and therefore the commands are failing and causing an error.

Full Specification

The specifications for authentication and digital signing are in NPFIT Spine 1.0 requirements.

The two known artefacts that reference the areas of code that NHS Digital believe need to change are outlined below.

 https://digital.nhs.uk/developer/api-specifications/spine-external-interface-specification

 EIS Part 6 – Spine security Broker (SSB)

• Describes the external interfaces required by system implementers to access the Spine Security Broker (SSB) to implement single sign-on.

• BT document - 2087 External Interface Specification: Part 6 Spine Security Broker

• Relevant Sections - 6.10 Client Signing Interface in this above document outlines the signing interface.

 EIS Part7 – Spine Security Broker (SSB) API

• Includes the formal specification of SSB Java and C APIs

• BT Document 2087  External Interface Specification: Part 7 Spine Security Broker APIs

• Relevant Sections - Section 7.7 PKCS example C,  Section 7.8 PKCS Example Java 

The above artefacts are currently the only known location outlining the detailed specification for how the PKCS11 API works and the example code for calling the API.

It is therefore the intention that this standard acts as guidance that looks to supersede relevant sections in the EIS part 6 and part 7 only, NHS Digital do not intend to fully review and uplift both documents and any dependent documents as this will be a time consuming and costly exercise for NHS Digital and the System suppliers with a number of unknown and unintended consequences should artefacts be uplifted and republished.

This is the first draft of the guidance and it is intended to work with a number of the Primary Care providers to update and finalise this guidance so that it represents an accurate picture of the end requirement and standard required to support Entrust and deprecate reliance on proprietary PKCS11 libraries/middleware methods.

Figure 1 – Diagrammatic representation of document hierarchy

Open

Overview - replaces section 6.10.1,

Current suppliers’ products adhere to the existing requirement for working with Smartcards on the Windows Platform which is to use the PKCS11 standard, however it inadvertently relies heavily on the vendor proprietary PKCS11 library to communicate with Smartcards as that was the middleware/solution in use at the time.

 As part of the next Smartcard procurement, NHS Digital intend to move to the PIV/CIV Standard which allows implementers to leverage Microsoft’s built-in APIs (available from Windows 7 SP1 and above). The PIV cards won’t have backwards compatibility with existing proprietary middleware libraries in use (e.g. gclib library).

 Part of the COVID-19 response accelerated the introduction of the Entrust virtual Smartcard solution, during assurance of which it became evident that partners who have implemented the PKCS11 DLLs have a number of issues that prevent authentication and signing actions from being performed when using the Entrust virtual Smartcard.

This means the following need to be taken into consideration:

1. Support for PIV Cards in the NHS Digital controlled Identity Agent 2.x.x ( and have been for some time) which, means they can be used successfully to perform Authentication via this Identity Agent. The legacy B.T. Identity Agent does not work with such Smartcards. It should be noted that the B.T. Identity Agent has been out of support for a significant period of time and as far as NHS Digital is concerned this has long been deprecated in favour of the NHS Digital 2.x.x Identity Agent which, is under active maintenance and development.

The B.T. Identity Agent will continue to work with the physical cards (Gemalto Cards and the Oberthur Cards, i.e. Series 4,5,6,8 cards) but PIV based Smartcards will not work with this product. Should PIV Cards (virtual or physical) be used in an environment, the NHS Digital Identity Agent will be required to successfully authenticate using such cards. Entrust Virtual Smartcards will not work with B.T. Identity Agent.

1. Suppliers’ applications that need to perform Advanced Electronic Signatures will not be able to perform it when presented with a PIV based Smartcard if they use BT Identity Agent. This is due to the lack of compatibility between the PIV Card and the legacy integration requirement. This will not change as the PKCS11 requirement is superseded and will be discussed in detail further in the documentation. 

A change to the suppliers’ application code is required so that full support for all legacy, current and future Smartcards can be provided whilst reducing the complexity of the integration for suppliers.

Client Signing Interface API  – replaces 6.10.2

The legacy proprietary Client Signing Interface API, which is marked for deprecation, is a subset of PKCS11 (also known as Cryptoki) which conforms to the OASIS PKCS11 Standard Version 2.01 specification.

The limited support for PKCS11 libraries for the Windows Platform and the cost to procure such libraries from manufacturers , coupled with the overhead for suppliers to manage the introduction of new cards into their application, are two major reasons why this interface has been marked for deprecation in favour of what is outlined below.
 

Support and Compatibility – replaces 6.10.3

NHS Digital have created a Smart Card API for performing Digital Signatures that match the EPS requirement (PKCS1 v1.5 SHA1). This is a Managed API component. This API is currently available for C# .NET 4.0 , C# .NET 4.5 , C/C++ with additional variants to be generated as and when required for supplier support. 

This API is 100% compatible with the current physical Cards (series 4, 5, 6) and series 8 working in compatibility mode as well as with its intended Middleware, the Entrust Virtual Smartcard (PIV) and in future the physical PIV Smartcards. This Managed API deprecates the use of proprietary PKCS11 in favour of the Microsoft Cryptographic APIs to work with the Smartcards which, has greater support from Manufactures and supports PIV Smartcards by default. The latter means that NHS Digital do not require a full roll out of Smartcard Middlewares on target machines in our estate, drastically reducing the complexity of roll out and adoption.

Smart Card Signing API replaces ‘PKCS11 API section 6.10.3.1’

By utilizing the new Smartcard API that is provided and maintained by NHS Digital, system integrators no longer have to worry about the Smartcard type or the complexities of individual Smartcard manufacturer implementations.  There is also no need for integrators to know the specific standards employed to communicate with the Smartcard nor do they need to perform session management to the Smartcard to invoke signing requests.

The API requires the following method calls to be made:

1. Create an instance of the signing object SCardDigitalSignature

2. Create a SHA1 hash of the data that is to be signed.

3. Invoke the ObtainTheSigningCertificate method on the signing object to retrieve the X.509 Certificate that supports Non-Repudiation for Digital Signatures.

4. Invoke the SignHashGeneratingPKCS1v1_5Signature method on the signing object passing in the Smartcard Name, Smartcard Pin Number , Signing certificate , the hash digest and hashing algorithm. If successful, the Base64 string representation of the PKCS1 V1.5 digital signature is returned through a call back variable.

The above steps are required to perform a signing operation with any supported Smartcard without the need to change the product code to support a future card unless NHS Digital update the interface. An example implementation can be seen further down in the documentation.

Storyboard – replaces section 6.10.4

To provide some context to the process by which an example application would use the Client Signing Interface, the following storyboard is presented. It is not intended as a definitive statement of application logic, but merely serves to illustrate how the Client Signing Interface could be used within an application.

It must be understood that only steps 5 and 6 of the Storyboard specifically relates to the Client Signing Interface – all other steps are performed by the example application.

Also, the generation of any other digital signature constructs (e.g. XML-DSIG) is also an application responsibility and is outside the scope of this document.

1. The user will be sat at a workstation having authenticated to the Spine with their smart card in the reader. This is user authentication and should not be confused with the requirement for a user to enter their passcode for the purposes of signing, although the same passcode is used.

2. The application workflow requires the user to commit to some content i.e. sign an electronic form.

3. The user is made aware that they are being requested to commit to the presented content and asked to Digitally Sign the form by pressing a ‘Sign’ button.

4. On pressing the ‘Sign’ button, a passcode dialogue appears and, the user enters their passcode, which is the same passcode used when authenticating.

5. The application creates an instance of the Digital Signing object and retrieves the X.509 Digital.

6. The application will then generate a hash of the form to be digitally signed and pass it to the Smartcard via the Digital Signing object whereupon a digital signed copy will be generated on the Smartcard and passed back to the application.

7. The application will then validate the chain of certificates up to the Spine Root CA. In essence, the application requires a trusted store containing the Spine Root CA certificate and the Sub CA certificate used to issue the Content Commitment Signing certificate. This chain will enable the application to establish that the Sub CA issued the signing certificate

8. The application will validate the user’s SSO Token, the principle being that a valid token can be accepted as confirmation that the user’s Smartcard and associated certificates and keys are currently valid at that time.

9. The application will then securely log details about the transaction, which may include information such as date and time, SSO Token validation status and the hash of the transaction.

Signing Process Psuedo Code – replaces 6.10.5

To perform a signing operation via the new NHD Digital Signing API the following API calls can be leveraged (this example pseudo code is provided in .NET.  Detailed examples for other languages exists in the API release pack). This is not all of the available API calls or settings however, it does show a number of the API methods that can be utilized to successfully perform a Digital Signing request regardless of the supplied Smartcard type.

//required for hashing algorithms and X.509 Certificates.
using System.Security.Cryptography
using System.Security.Cryptography.X509Certificates;

//include the signing API reference and declare the namespace we are to use.
using HSSCardCryptoSign;

. . . further application code . . .
var res = 0;

var readerName = “OMNIKEY CardMan 3x21 0”;
var pinNumber = “1234”;

X509Certificate2 signingCert = null;
var signature = String.Empty;

//create an instance of the Smart Card Digital Signing class.
var scdsObj = new SCardDigitalSignature();

//create an instance of SHA1 Hashing object.

var SHA1 = new SHA1Managed();
var dataToHash = “The Quick Brown Fox Jumped Over The Lazy Goose”;

//validate that the provided pin number is valid.
res = scdsObj.isPinValid(readerName,pinNumber);
if (res != 0)

{

       throw new ApplicationException($"Failed validate pin number.                                 {scdsObj.ErrorCodeToString(res)}");

}

//get the X.509 Certificate
res = scdsObj.ObtainTheSigningCertificate(readerName,out signingCert);

if (res != 0)

{

       throw new ApplicationException($"Failed to obtain the signing certificate. {scdsObj.ErrorCodeToString(res)}");

}

//compute the hash for signing

var inHash = SHA1.ComputeHash (Encoding.ASCII.GetBytes(dataToHash));

//create the digital signature

res = scdsObj.SignHashGeneratingPKCS1v1_5Signature(readerName,

             pinNumber,

             signingCert,

             inHash,

            "SHA1",

            out signature);

if (res != 0)

{

       throw new ApplicationException($"SignHashGeneratingPKCS1v1_5Signature failed. {scdsObj.ErrorCodeToString(res)}");

}

//if the X.509 Signing certificate is needed in Base64 encoded ASN.1
var signingCertBase64 = Convert.ToBase64String(signingCert.RawData);

Application Responsibilities – replaces section 6.10.6

The Client Signing Interface is a relatively small part of the overall process of achieving Content Commitment within an application. Most of the responsibility falls on the applications in terms of presenting the content in an appropriate manner, preparing the content for signing, requesting the passcode from the user, signing, validating and then securely logging the transaction.

Single or Bulk signing replaces section 6.10.7

Applications may require a user to sign individual transactions or multiple transactions i.e. different signing models. The signing interface allows for different signing models to suit application needs.

In order to create a signature, the card must be logged in using the user passcode (which the application must prompt the user for). Then, one or more messages can be hashed and signed. However, it maybe that the passcode is required to be entered each time a message is signed.

Assurance Approach

Overview:

NHS Digital are looking to take a simple approach to assurance

1. Collaborative working at the developer level to understand code changes required

2. Early proving of capability in INT with end to end systems to confirm issues with authentication and signing work with EPS and pharmacy systems.

3. GP System suppliers to run a functional and non-functional regression pack that mitigates the risks identified by the GPITF assurance risk assessment and that satisfies GP System supplier’s own assurance requirements given this is a critical function.

NHS Digital are looking to work collaboratively with the system providers to provide some workable code.  NHS Digital have worked at the developer to developer level to explain, guide and support the changes required. This has been well received so far as there are gaps in knowledge of historic code that has remained untouched for a number of years and because we have found that the digital signing operation may not be the only place the Smartcard is being leveraged by the application and, NHS Digital have the capabilities to help guide the developers to make any additional changes that are required.

Early proving in INT has confirmed that the issues already identified with the Entrust VSC have been addressed and that the GP Systems can read the keys from the appropriate slot for signing and that the end to end signing functions appear to work, subject to a regression pack run by the suppliers.

Assurance Stages:

Assurance Stage 1 (confirmed as successfully completed by the issue by NHS Digital of the DevMac)

 In order to successfully meet the stage 1 criteria then the suppliers will have:

1. Demonstrated early proving in INT by successfully authenticating using an Entrust virtual Smartcard and an end to end prescription signing test with EPS.

2. Run agreed regression test packs that cover authentication and EPS signing with particular focus the following areas outlined in the risk log attached:

• Regression test of National Service Integration

• Regression test of prescription signing

• Regression of two areas of Information Governance concern

• Regression testing of Smartcards and other

• Non-functional regression (no degradation of performance)

• Non-functional regression test of other access methods (eg VDI)

• Regression around other subsidiary suppliers to be considered

• RFO regression to be considered  

The risk log is attached:

Open

Further assurance requirements maybe identified during initial dialogue and collaborative working.

Assurance Stage 2 (confirmed as successfully completed by the issue by NHS Digital of the DevMac Full Rollout Approval (FRA))

Assurance stage 2 is demonstrating capability in live use which will be via a short pilot.

The pilot acceptance criteria for DevMAC FRA is:

• Deployed and in use in with 2 GP sites for authentication and signing prescriptions

• Deployed and used for 25 authentications without any Sev1-3 incidents

• Deployed and used to sign 50 prescriptions without any Sev1-3 incidents

• In use for two weeks without any Sev1-3 incidents. (duration window to be confirmed closer to the pilot)