CD Encryption Directive: Practical Implementation Challenges

Dr William Saywell

MA, BM, BCh (Oxon), Dip Med Inf (RCS Ed), FRCR

Consultant Radiologist and CfH Clinical Lead

David Nicholson’s letter (Extract 1)September 2008

Dear Chief Executive

DATA SECURITY

Further to my letter of 20 May 2008 I am writing to ask you to conduct a review to ensure that your

organisation has fully implemented the policy that all removable data must be encrypted. I would also like

to draw your attention to the report of the Cabinet Office Data Handling Review that was published on

30 June 2008, which contains mandatory security standards for the public sector. A second report, the

Thomas/Walport Data Sharing Review, is also relevant and whilst the government response to the

recommendations in this report has not yet been finalised, it is likely that all will be accepted.

PACS encryption

The encryption mandate applies equally to PACS images whether on CD or back-up tapes. There could

be occasional exceptions on patient safety grounds such as a severely ill patient being transferred to

another hospital where the time to encrypt could cause a danger to the patient and a risk assessment will

need to be made.

David Nicholson’s letter (Extract 2)How not to do it?

At present, it is typically a three or four step process to encrypt images onto a CD from a PACS system:

1. PACS burns an unencrypted CD which is then loaded into a PC. 2. SafeBoot (the centrally procured software) encrypts the files on the PC. 3. The PC burns a new CD with the encrypted files. The unencrypted CD should then be destroyed in line with the guidance at Annex 3. 4. A PACS viewer can be incorporated with the CD to enable the image to be opened on any PC –information regarding this will be made available to trusts shortly. The CD and the password MUST be transferred by different routes.

If compression is used to reduce the size of a PACS image, it must be “Lossless compression”, otherwise image quality may be affected (some applications combine encryption and compression which may have created the myth about encryption).

It may be that other, locally procured software is being used but you will wish to check that all trusts are using encryption appropriately.

NHS CFH is working with PACS suppliers and McAfee to make changes to PACS systems to enable encrypted CDs to be burned directly from the PACS systems. In addition, following a successful pilot, it is intended to rollout a nationally scaled solution for bulk secure file transfer by January 2009. This will allow any file between 20MB and 1GB to be transferred securely across N3 (smaller files can be transferred via NHSmail).

And at the other end?

Viewing by clinicians is quite easy – but what about import to PACS?

GE PACS – If you decrypt the CD on the RA600 workstation the viewer opens. Whilst this is still open, browse to C:\NHS_CfH_DICOM_Images\Find the DICOMDAT folder (if a GE CD) or the variably-named folder containing the DICOM files (if a Sectra CD) and copy to the PACS import folder.

Sectra PACS – Decrypt the CD and with the viewer open navigate as above. Copy the files to another (3rd!) CD and insert in Sectra workstation's CD drive (D:)

What about Passwords?

From the CfH PACS FAQs:12. What happens if the password for the CD is lost?• The creator of an encrypted CD will need to implement

processes and procedures to ensure that the password can be recovered. These should address such issues as ensuring that:

• The passwords are stored securely and backed-up appropriately.

• The passwords are retained as long as they are needed. • Requests for passwords are sufficiently authenticated to be

legitimate. • Requests for passwords can be serviced in an appropriately

timely fashion.

Alternatives to CDs

• DICOM communications• PACS Exchange (London)• 3rd party solutions (eg BB Rad)• SFTP• PACS Webview (especially if facilitated by the PACS Portal)• Future developments

– GE Broadview– XDSi– Etc

• However, few of these are currently useable outside the N3 environment.

Alternatives to Encryption

• The guidance has been relaxed a little, subject to Trust risk assessment.

• Unencrypted by hand of patient• Unencrypted by Secure Courier – subject to:

– the risks being understood, accepted and owned by the trust board; – the number of patients involved is no more than four in the case of each

transfer; – and the media is tracked in transfer with robust signatory processes for

despatch and delivery.– Expensive, and still an administrative overhead for Tracking –

matching despatches against confirmed receipt.– To and from Independent Sector excluded

• Unencrypted where patient safety might be compromised.

How best to do it?What is required?

• Sender– From PACS workstation (or perhaps a connected

PC).

– Minimal extra user input– Easy procedure for non-technical admin staff– Password management built in– Doesn’t need extra consumables (CDR or CDRW)

How best to do it?What is required?

• Recipient– Access to help on the CD

• Technical instructions• How to obtain missing password

– Security – no files retained on hard drive– Clinical Users

• Ease of viewing – will it pass the ‘orthopod test’?– PACS Administrators

• Ease of importing to PACS • Retain flexibility

Options for CD encryption

• PACS Vendor solution– Eg GE Ultima (£20k)

• 3rd Party Vendor– Several have posted on the forum– Probably cheaper than PACS vendor, but still costly

• McAfee/Safeboot– Free of charge (apart from extra consumables),

but time-consuming.

• Or...

• DIY solutions– Using freeware applications for scripting,

encrypting and burning– Pro: Free– Con: needs sad old geek to compile it!– DOI – I am that SOG!– Those here earlier will have seen my solution

demonstrated at lunchtime.– Currently it works on GE and Sectra PACS (and

nearly ready for E-Film stand-alone burner).– Agfa ????? Certainly not at present but I’d be

happy to try.

Features

Passwords

• An essential element of encryption– Public/Private key systems are an alternative– NHSIA once had a plan for key escrow, but it never got off the drawing

board

• Need to consider – Strength– Management

Password Strength

• There are extant NHS guidelines– www.connectingforhealth.nhs.uk/systemsandservice

s/nsts/security/batch/ Password.rtf

http://www.connectingforhealth.nhs.uk/systemsandservice

• NSTS Password/phrase guidelines for batch encryption to AES 256 bit strength•

While it has been reported that it might be necessary to use a password/phrase as long as 64 characters to take full advantage of AES 256-bit encryption, we recommend that a pass-phrase of no less that 12 characters is used for encryption of NSTS batch trace files. This achieves a good compromise between security and usability.

• For optimal effect, a password/phrase should therefore:• Be at least twelve characters long;• Contain a mix of alphabetic, numeric and ‘special’ characters (such as ; - < ? #);• not use an alphabetic or numeric series, either backwards or forwards (i.e. ABCDEFG,

GFEDCBA, ABCABCABC 1234567 or 7654321, 123123123);

• not use a string of identical letters or numbers (i.e. AAAAAAA or 1111111);• not use a common keyboard shortcut (i.e. ASDFG or QWERTY).• A pass-phrase is to be preferred and might be something like:• A ‘pseudo’ phrase such as 5pm_Go_Walking (please don’t use this!);• A ‘word’ using the first one or two characters from a sentence plus some added special

characters (such as ev go_bo de fa short for ‘every good boy deserves favour’ which some of you may recall from music lessons);

• A sentence, perhaps with additional characters, selected from a book or newspaper.• Passwords/phrases should, of course, be changed regularly and not less frequently than

every month. For batch encryption one can use a fresh pass-phrase for each batch, of course.

• NSTS Service Management Team December 2007

Password Strength

• There are extant NHS guidelines– www.connectingforhealth.nhs.uk/systemsandservices/nsts/security/b

atch/ Password.rtf• 7-zip provide an illustration of how length affects decryption time• Here is an estimate of the time required for an exhaustive password

search attack, when the password is a random sequence of lowercase Latin letters.

• We suppose that one user can check 10 passwords per second and an organization with a budget of about $1 billion can check 10 billion passwords per second. We also suppose that the processor in use doubles its performance every two years; so, each additional Latin letter of a long password adds about 9 years to an exhaustive key search attack.

• The result is this estimate of the time to succeed in an attack:

http://www.connectingforhealth.nhs.uk/systemsandservices/nsts/security/b

Password Length Single User Attack Organization Attack

1 2 s 1 s

2 1 min 1 s

3 30 min 1 s

4 12 hours 1 s

5 14 days 1 s

6 1 year 1 s

7 10 years 1 s

8 19 years 20 s

9 26 years 9 min

10 37 years 4 hours

11 46 years 4 days

12 55 years 4 months

13 64 years 4 years

14 73 years 13 years

15 82 years 22 years

16 91 years 31 years

17 100 years 40 years

Password Practicalities

• Strength appropriate to the threat– NSA or GCHQ will be able to crack it regardless!– Need not be OTT like SFTP site

• Practical to set• Practical to transcribe into DOS text box• Cryptography isn’t the biggest threat anyway

– Social engineering– Rubber hose cryptography

Regulation of Investigatory Powers Act 2000

RIPA Part III

Part III of the Regulation of Investigatory Powers Act 2000 (RIPA) came into force on 1 October 2007.

Key points to note:

Part III provides a statutory framework that enables public authorities to ensure that protected or encrypted electronic information which they have obtained lawfully or are likely to obtain lawfully can be put into intelligible form.

It is a criminal offence to refuse requests for such disclosure and encryption codes.

Finally, a Word of Warning!

• Unlikely to apply to medical users?• Recent case of terrorist bomber who was a

doctor.

• Suspicion fell on colleague (subsequently acquitted).

• Having encrypted data on the PC, with a lost or forgotten password would not have made the defence case easier!

• So shred those PCs once they’ve been imported to PACS or have been finished with.

Any Questions?