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.

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.

...

       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:

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

Assurance Stage 2 );

}

//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 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)

Payment Rules (Stage 1 and Stage 2 are defined in the assurance approach above)

...

Stage 1 - 50% of the Incentive Amount on DevMac receipt with a sliding Scale of 100% on or before 14th September 2020 reducing by 5% each calendar day until 28^th September 2020 and remaining at 25% until 5^th October 2020 and zero beyond the 5^th October 2020. Payment subject to achieving Stage 2 by 12^th October 2020.

...

)

 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:

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)