UNCLASSIFIED

(1)

11936884

CPA SECURITY CHARACTERISTIC

GATEWAY EMAIL ENCRYPTION

Version 1.0

(2)

CPA Security Characteristics for Gateway Email Encryption 1st March 2012 Document History

Version Date Description

0.0 13th January 2012 Preparation for industry review 1.0 1st March 2012 Updates following industry review

This Security Characteristic is derived from the following files

File Name Version

Gateway Email Encryption – v1.3.cxl 1.3 Common Email Encryption – v1.3.cxl 1.3 Common Libraries – v1.6.cxl 1.6 Crypt Libraries – v1.4.cxl 1.4 Hardware Libraries – v1.3.cxl 1.3

Soft copy location

DiscoverID 11936884

This document is authorised by:

Deputy Technical Director (Assurance), CESG

This document is issued by CESG

For queries about this document please contact: CPA Administration Team

CESG Hubble Road Cheltenham Gloucestershire GL51 0EX United Kingdom Tel: +44 (0)1242 221 491 Email: [email protected]

The CPA Authority may review, amend, update, replace or issue new Scheme Documents as may be required from time to time.

(3)

CPA Security Characteristics for Gateway Email Encryption 1st March 2012

REFERENCES

[a] The Process for Performing Foundation Grade CPA Evaluations, v1.3, CESG [August 2011]

[b] NIST SP 800-90 – Recommendation for Random Number Generation Using Deterministic Random Bit Generators [2007]

[c] RFC 4880 – OpenPGP Message Format [November 2007]

[d] RFC 5751 – Secure Multipurpose Internet Mail Extensions, version 3.2 [January 2010]

[e] RFC 5321 – Simple Mail Transfer Protocol [October 2008] [f] RFC 1939 – Post Office Protocol – version 3 [May 1996]

[g] RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security [February 2002]

[h] RFC 2595 - Using TLS with IMAP, POP3 and ACAP [June 1999] (updated by RFC 4616)

[i] RFC 4616 - The PLAIN Simple Authentication and Security Layer (SASL) [August 2006] (updates RFC 2595)

[j] RFC 5408 – Identity-Based Encryption Architecture and Supporting Data Structures [January 2009]

[k] HMG IA Standard No. 5 - Secure Sanitisation, issue 4.0 [April 2011]

[l] HMG IA Standard No. 7 - Authentication of Internal Users of ICT Systems Handling Government Information, issue 4.0 [October 2010]

[m] CESG Good Practice Guide No. 35 – Protecting an Internal ICT Network, issue 2.0 [August 2011]

(5)

I. OVERVIEW

1

1. This document is a CPA Security Characteristic – it describes requirements for 2

a particular type of assured product for evaluation and certification under CESG‟s 3

Commercial Product Assurance (CPA) scheme. 4

A. Product Aims

5

2. Email encryption products are intended to protect the confidentiality and 6

integrity of emails in addition to providing the recipient with authentication of the 7

sender. 8

3. “Gateway Email Encryption” in the context of this Security Characteristic refers 9

to a mail transfer agent that transparently applies and removes protection for email 10

messages as they transit the boundary of a secure network. 11

4. This protection is: 12

a) Applied to an email through encryption and digital signing. 13

b) Removed from an email through decryption and digital signature 14

validation. The recipient is made aware if an email fails authentication 15

during removal of protection. 16

B. Typical Use Case(s)

17

5. The encrypted email gateway acts on behalf of the secure network, 18

communicating with remote encrypted email endpoints, which may be other 19

encrypted email gateways or desktop email encryption products. 20

a) Outbound protection – the product encrypts the email for each recipient

21

and signs the email to ensure integrity of delivery. The email is then sent 22

to the destination address. 23

b) Inbound email receipt – the product attempts to cryptographically

24

validate the signature and decrypt any protected emails it receives for 25

local recipients. The decrypted email and/or any error/warning messages 26

are then sent to an internal email server for onward distribution. 27

C. Expected Operating Environment

28

6. An encrypted email gateway is expected to be installed within a physically 29

secure environment and logically sited at the boundary of a security domain, 30

bordering a less trusted network (such as the Internet). 31

(6)

7. In the envisaged architecture (see Figure 1), all email traffic that is generated 32

within the local security domain for recipients outside of the domain will be routed to 33

the gateway. The gateway will then apply confidentiality, integrity and/or 34

authentication cryptographic protection according to rules determined by the 35

gateway‟s policy, before sending the resultant email traffic over the less trusted 36

network to other encrypted email endpoints. 37

38 39

40

8. Similarly, the encrypted email gateway will process incoming email traffic 41

received over the untrusted network. In this, it will attempt to (a) cryptographically 42

verify any digital signature and (b) decrypt the incoming email, before forwarding it to 43

the recipient endpoints via the email server. Note: the security domain in which the 44

encrypted email gateway is deployed should be protected according to the guidance 45

in Reference [m]. 46

9. In Figure 1, in order for the security domains to interact with each other, each 47

domain needs to be able to access/retrieve public keys of remote endpoints for 48

encryption and digital signature validation. The authenticity of these public keys is 49

protected by a key management solution, in which one or more trusted entities 50

cryptographically bind the key with the endpoint‟s identity, allowing the product to 51

digitally verify the binding. Other details about the key management solution are 52

beyond the scope of this document. 53

Figure 1: Operating Environment for Encrypted Email Gateway

Security Domain #3 (not using Gateway Email Encryption)

Email Client Email Client Security Domain #2 Security Domain #1 Encrypted Email Gateway Email Server Email Client Email Client Encrypted Email Gateway Email Server Untrusted Network Encrypted Email Client Encrypted Email Client Email Server Gateway

(7)

D. Compatibility

54

10. An encrypted email gateway product may exist as either a dedicated hardware 55

device or as one or more software modules, deployed on a general purpose platform. 56

11. In either case, this Security Characteristic does not place any specific hardware 57

requirements upon the product beyond its normal technical requirements. For 58

example, some products may have specific CPU or memory requirements in order to 59

function effectively. This Security Characteristic does not define minimum hardware 60

requirements. 61

E. Interoperability

62

12. An encrypted email gateway product must support the following algorithms 63

when applying and removing cryptographic protection: 64

Algorithm Type Approved Algorithm/s

Symmetric Encryption AES-128-CBC, and/or

AES-128-CFB Key Wrap (Key Encryption) AES-128 Key Wrap

Session Key Agreement ECDH-256, and/or

DH-based 1536/192

Hash Function SHA-256

Digital Signing ECDSA-256, and/or

DSA 1536/192 65

13. The product is likely, but not necessarily required, to interoperate with one or 66

more of the following: 67

a) Widely-used open-standard encrypted email protocols, such as OpenPGP 68

and S/MIME (references [c] and [d]) 69

b) General email messaging protocols, such as SMTP (Reference [e]) 70

c) PKI management nodes, such as certification authorities, public key 71

servers, public key repositories, etc 72

d) Email-aware anti-malware and content filtering products 73

e) Network management protocols, such as SNMP to assist management of 74

multiple corporate gateways 75

(8)

F. Variants

76

14. This Security Characteristic has the following variants: 77

a) Gateway Platform 78

i) Software Gateway - The Email Encryption Gateway is software that 79

is deployed onto standard server hardware running a general 80

purpose operating system. 81

ii) Hardware Gateway - The Email Encryption Gateway is a dedicated 82

hardware device, for direct deployment into a network. 83

b) Encrypted Email Type 84

i) OpenPGP - Email cryptographically protected using OpenPGP 85

security mechanisms 86

ii) SMIME - Email cryptographically protected using S/MIME security 87

mechanisms 88

iii) Bespoke - Email cryptographically protected using a bespoke 89

security mechanism (i.e. not OpenPGP or S/MIME) 90

G. High Level Functional Components

91

92

Figure 2: Gateway Email Encryption Product Components

93

Gateway Email Encryption Product

Email Message Processing

Encryption Decryption RNG Key Store Policy Management Account Management Email Management Client Interfaces

Local Traffic Interface (RED) _{External Traffic Interface (BLACK)}

(9)

15. The functionality of the device can be broken down in to the key components 94

shown in Figure 2, described as follows: 95

 Email Management 96

Handles the general management of emails within the gateway product. 97

98

 Account Management 99

Handles the management of email accounts in terms of identities and associated 100 keys. 101 102  Policy 103

A set of rules, enforced by the encrypted email gateway, which determine the 104

cryptography applied to incoming and outgoing email messages. It is expected to 105

incorporate default rules that cover requirements specific to the local security domain 106

in which the gateway is deployed. 107

108

 Key Store 109

A local storage mechanism for the required keys for each user on the intranet side of 110

the gateway and the gateway itself. It may also need to have access to (or store 111

locally) public keys of remote end users/gateways. 112

113

 RNG 114

The Random Number Generator generates random data primarily for symmetric 115

content encryption keys and IVs. It also generates any random components required 116

in digital signature generation. 117

118

 Email Message Processing 119

Handles the encoding and decoding of email messages including the application of 120

cryptographic mechanisms such as encryption, decryption, digital signing/verification. 121

Options for the processing are expected to be constrained according to policy. 122

123

 Local Traffic Interface (RED) 124

The local traffic interface deals with email traffic received from and destined to 125

clients/servers within the local (trusted) domain. 126

127

 External Traffic Interface (BLACK) 128

The external traffic interface deals with encrypted email traffic leaving and entering 129

the local domain and will interface (via untrusted or less-trusted networks, such as 130

the Internet) to other encrypted email gateways, which may be via intermediate 131

servers and relays. 132

(10)

H. Future Enhancements

133

16. At the time of writing, there exist Identity Based Encryption (IBE) standards (e.g. 134

RFC 5408, reference [j]) and IBE email products. Future revisions of this document 135

may additionally cover IBE implementations of gateway email encryption. 136

17. CESG welcomes feedback and suggestions on other possible enhancements to 137

this Security Characteristic. 138

(11)

II. SECURITY CHARACTERISTIC FORMAT

139

18. All CPA Security Characteristics contain a list of mitigations which are split into 140

three requirement categories: development, verification and deployment 141

requirements. Within each of these sets the mitigations can be grouped based on 142

areas of the product (as illustrated in the High Level Functional Component Diagram 143

above), such as bulk encryption or authentication, or they may be overarching 144

requirements which apply to the whole product. Reference [a] describes how 145

evaluation teams should interpret Security Characteristic. 146

19. The three types of mitigations are denominated as follows: 147

 DEV – These are mitigations that are included by the developer during the 148

design or implementation of the product. These are validated via a review of the 149

product‟s design or implementation during a CPA evaluation. 150

 VER – Verification mitigations are specific mitigations that the evaluator must 151

test during the assessment of the product. 152

 DEP – Deployment mitigations are points that must be considered by users or 153

administrators during the deployment of the product. These mitigations are 154

incorporated into the security procedures for the product. 155

156

20. Each mitigation includes informational text in italics, describing the threat that it 157

is expected to mitigate. It also lists at least one specific mitigation, which describes 158

what must actually be done to achieve that requirement. In some cases there is 159

additional explanatory text which expands upon these requirements. 160

21. In the requirements listed below, the following terminology can be used: 161

 „Must‟, „Mandatory‟ and “Required” are used to express a mitigation that is 162

essential. All mitigations and detailed mitigations are mandatory unless there is 163

an explicit caveat, such as „if supported by the product‟. 164

 „Should‟ and „Strongly Recommended‟ are used whenever a requirement is 165

highly desirable, but is not essential. These are likely to become mandatory in 166

future iterations of the Security Characteristic. 167

 „Could‟ and „Recommended‟ are used to express a non-mandatory requirement 168

that may enhance security or functionality. 169 170 22. For example: 171 DEV.M1: [A mitigation] 172

This mitigation is required to counter [a threat] 173

At Foundation the product must [do something].

174

This can be achieved by [explanatory comment]. 175

(12)

III. REQUIREMENTS

176

A. Design Mitigations

177

DEV.M102: Address Space Layout Randomisation 178

This mitigation is required to counter exploitation of a software implementation 179

error 180

At Foundation Grade the product is required to be compiled with full support

181

for ASLR, including all libraries used

182

ASLR may be disabled for specific aspects of the product, provided there is 183

justification of why this is required. 184

DEV.M123: Crash reporting 185

error 187

At Foundation Grade the product is required to ensure crashes are logged

188

Where it is possible that sensitive data may end up in the crash data, this 189

must be handled as red data and must only be available to an administrator. 190

Crash data from both the product and the underlying operating system must 191

be considered. 192

DEV.M125: Data Execution Protection 193

error 195

At Foundation Grade the product is required to support Data Execution

196

Protection (DEP) when enabled on its hosting platform and must not opt out of

197

DEP

198

If the product is to be specifically deployed on a platform that does not 199

support either Software DEP or Hardware-enforced DEP, there is no 200

requirement for DEP compatibility. 201

DEV.M149: Heap hardening 202

error 204

At Foundation Grade the product is required to use the memory management

205

provided by the operating system, products should not implement their own

206

heap

207

DEV.M177: (Hardware Gateway ONLY) Protection of sensitive data lines 208

This mitigation is required to counter installation of hardware-level malware 209

At Foundation Grade the product is required to ensure physical access to

210

internal data lines carrying sensitive data requires breaching of the tamper

211

protection

212

In this context, sensitive data is defined as key material, user data and 213

configuration data. 214

DEV.M194: Stack protection 215

error 217

At Foundation Grade the product is required to be compiled with support for

218

stack protection in all libraries, where the tool chain supports it

219

If more recent versions of the toolchain support it for the target platform then 220

they should be used in preference to a legacy toolchain. 221

(13)

DEV.M203: Update product 222

This mitigation is required to counter exploitation of a software logic error 223

error 225

At Foundation Grade the product should support the use of software updates

226

DEV.M204: (Software Gateway ONLY) Secure Software Delivery 227

This mitigation is required to counter installation of malware on host 228

This mitigation is required to counter installing compromised software using the 229

update process 230

At Foundation Grade the product should be distributed via a cryptographically

231

protected mechanism, such that the authenticity of software can be ensured.

232

Initial code for the product, and any subsequent updates, must be distributed 233

in such a way that tampering is cryptographically detectable. The recipient of 234

the software must be able to ensure the identity of the originator (i.e. vendor). 235

DEV.M214: (Software Gateway ONLY) User least privilege 236

This mitigation is required to counter taking advantage of existing user privilege 237

At Foundation Grade the product is required to operate correctly from a

238

standard account without elevated privileges

239

DEV.M261: Facility to purge all secrets before disposal 240

This mitigation is required to counter recovery of secrets from a 241

decommissioned or recommissioned device 242

At Foundation Grade the product is required to provide the capability to

243

securely erase keys and secrets during disposal

244

DEV.1 - Design >> Administrator Access Control 245

DEV.1.M106: Anti Hammer 246

This mitigation is required to counter dictionary and exhaustion attacks 247

At Foundation Grade the product is required to have a mechanism for limiting

248

the rate of login attempts

249

DEV.1.M150: Inform administrator of account activity 250

This mitigation is required to counter exploitation of poor management of 251

passphrases by the administrator 252

At Foundation Grade the product should display recent authentication history

254

It is recommended that on login the user be notified of the date and time of 255

the last successful login and any failed login attempts since the last 256

successful login. 257

258

If recent authentication history is displayed, it is strongly recommended that 259

users are told what to do, preferably on the screen, if the history is not what is 260

expected. 261

DEV.2 - Design >> Decryption 262

DEV.2.M258: Sanitise temporary variables 263

This mitigation is required to counter reading remnant volatile memory 264

At Foundation Grade the product is required to sanitise temporary variables

265

containing sensitive information as soon as no longer required

266

A secure erase must consist of at least one complete overwrite with a fixed or 267

random pattern and subsequent verification. 268

(14)

DEV.2.M262: Ephemeral keys protected from high risk processes 269

This mitigation is required to counter compromised device exfiltrating keys 270

At Foundation Grade the product is required to use operating system

271

mechanisms (process separation, etc) to protect ephemeral secrets

272

DEV.2.M263: Warn if expired keys were used to remove cryptographic protection 273

This mitigation is required to counter key/passphrase being used enough times 274

to significantly increase the chances of a brute-force attack succeeding 275

This mitigation is required to counter key/passphrase validity periods not 276

enforced on new application of key/passphrase 277

At Foundation Grade the product is required to generate a warning to indicate

278

that the protected content (a) have not been adequately encrypted and/or may

279

(b) not be authentic, indicating when the affected key(s) expired

280

The warning details shall in turn be forwarded by the deployment such that 281

they will be displayed to the user endpoint on opening the affected email. 282

DEV.2.M266: Warn user if non-approved cryptographic algorithm is encountered 283

This mitigation is required to counter exploitation of weak cryptographic 284

algorithm 285

At Foundation Grade the product is required to generate a warning to indicate

286

that the protected content may (a) have not been adequately encrypted and/or

287

(b) not be authentic, giving the reason(s) why (e.g. use of unapproved DES

288

encryption algorithm)

289

The warning details shall in turn be forwarded by the deployment such that 290

they will be displayed to the user endpoint on opening the affected email. 291

DEV.2.M271: Log failures to decrypt emails 292

This mitigation is required to counter MITM redirecting message to a different 293

destination 294

This mitigation is required to counter MITM corrupting decryption parameters 295

This mitigation is required to counter MITM corrupting ciphertext 296

This mitigation is required to counter MITM changing recipient key identifier to 297

one denoting a different recipient 298

one that has expired or been revoked 300

At Foundation Grade the product is required to log receipt of encrypted email

301

message that cannot be decrypted

302

The gateway (and its deployment) must also ensure that the recipient 303

endpoint is alerted to the decryption failure. 304

DEV.3 - Design >> Email Message Processing 305

DEV.3.M224: Extend BCC Privacy to decryption details in encrypted email messages 306

This mitigation is required to counter BCC recipient being visible to other 307

recipients due to details in decryption headers 308

At Foundation Grade the product is required to ensure a BCC recipient is not

309

identifiable from any of the fields (encrypted or unencrypted) in an encrypted

310

email message

311

Further, the decryption details for a given BCC recipient in an email 312

addressed to multiple recipients should only be present in the copy of that 313

email that is sent to that specific BCC recipient. 314

(15)

DEV.3.M226: (Bespoke Protocol ONLY) Bespoke Protocol implemented according to 315

developer's Functional Specification 316

This mitigation is required to counter exploitation of vulnerabilities in the 317

bespoke key exchange or digital signature protocol 318

This mitigation is required to counter exploitation of bespoke protocol 319

vulnerability 320

At Foundation Grade the product is required to implement the bespoke email

321

protection protocol in accordance to the developer's functional specification

322

The developer must have a functional specification for the protocol used to 323

cryptographically protect the emails as they are encrypted and signed, and 324

must provide evidence to the evaluator that the product accurately 325

implements this specification. 326

DEV.3.M228: (OpenPGP Protocol, SMIME Protocol ONLY) RFC compliant 327

implementation 328

This mitigation is required to counter exploitation of vulnerabilities in the key 329

exchange or digital signature protocol 330

At Foundation Grade the product is required to implement the latest RFC(s) for

331

the implemented encrypted email mechanisms

332

For instance, use RFC 4880 for OpenPGP encrypted email, RFC 5751 for 333

S/MIME, etc. 334

DEV.3.M231: Verification of certificates immediately prior to use 335

This mitigation is required to counter replacement of valid recipient certificate 336

with one associated with a compromised key 337

This mitigation is required to counter a private signing key of a trusted key 338

management entity becoming compromised 339

At Foundation Grade the product is required to check the authenticity of a user

340

encryption/signing key, before using it, through verification of the associated

341

certificate's digital signature back to a trusted key management entity

342

(including revocation checks)

343

Approved digital signing algorithms are listed in the Interoperability section. 344

DEV.3.M233: (OpenPGP Protocol ONLY) Strict OpenPGP header parsing operation 345

and rejection of invalid fields 346

This mitigation is required to counter exploitation of non-standard header fields 347

in encrypted email 348

At Foundation Grade the product is required to reject any non-standard

349

OpenPGP headers

350

Such as marking a header field for experimental use 351

DEV.3.M237: (SMIME Protocol ONLY) Restrict ASN.1 encoding permutations 352

This mitigation is required to counter use of non-DER ASN.1 encoding options 353

This mitigation is required to counter use of excessively large primitive values in 354

the ASN.1 encoding 355

At Foundation Grade the product is required to reject encodings that are not

356

conformant to ASN.1 Distinguished Encoding Rules (DER)

357

DEV.3.M239: Use of constrained encoding format 358

This mitigation is required to counter modification of unencrypted headers to 359

introduce malware 360

At Foundation Grade the product is required to restrict allowable encoding

361

permutations for unencrypted headers (e.g. use DER for ASN.1, prohibit

362

deprecated encoding options where possible, etc)

(16)

DEV.3.M241: (OpenPGP Protocol ONLY) An implementation will only generate V4 364

certificate packets 365

This mitigation is required to counter exploitation of older format of packet 366

header in email 367

This mitigation is required to counter exploitation of a weak V3 certificate packet 368

At Foundation Grade the product is required to provide backward compatibility

369

when decoding old V3 signature packets, but always use V4 for generating

370

new signature packets

371

DEV.3.M246: Do not add email headers that could assist an attacker 372

This mitigation is required to counter exploitation of gateway model/software 373

details reported in email headers 374

At Foundation Grade the product is required to not include model or software

375

identifier for the gateway in outgoing email headers that may allow an attacker

376

to exploit known weaknesses in the gateway

377

DEV.3.M269: Email processing resource management 378

This mitigation is required to counter MITM targeting gateway with excessive 379

amounts of plausibly-formatted encrypted emails 380

This mitigation is required to counter red side user sending excessive amounts 381

of email traffic via the gateway 382

This mitigation is required to counter MITM targeting gateway with replay of 383

intercepted encrypted emails 384

This mitigation is required to counter MITM intercepting encrypted emails and 385

sending failure responses back to originating gateway 386

At Foundation Grade the product is required to limit resources that can be

387

consumed by the gateway by a single connection

388

DEV.3.M272: Log use of expired or previously revoked public key identifier for 389

recipient 390

one that has expired or been revoked 392

At Foundation Grade the product is required to log attempts to encrypt using

393

expired/revoked key data

394

This is to assist identification of attack sources. 395

DEV.3.M273: General Resource management 396

This mitigation is required to counter memory exhaustion through excessive 397

general incoming network traffic 398

At Foundation Grade the product is required to limit resources that can be

399

consumed through the processing of incoming network traffic (i.e. non-email

400

related)

401

DEV.3.M274: Log any mismatch between email address and public key identifier for 402

recipient 403

one denoting a different recipient 405

This mitigation is required to counter MITM redirecting message to a different 406

destination 407

At Foundation Grade the product is required to log a mismatch between email

408

address and public key identifier for recipient

409

Additionally, the gateway is expected to attempt to decrypt the message using 410

known cryptographic keys for the given recipient and sender as identified by 411

the email addresses. If the decryption succeeds, the recipient is notified that 412

the message was potentially tampered with. Otherwise the recipient is notified 413

of the decryption failure. 414

(17)

DEV.4 - Design >> Encryption 415

DEV.4.M220: Ensure nonce mechanisms do not repeat 416

This mitigation is required to counter exploitation of repeated protective number-417

used-once ('nonce') 418

At Foundation Grade the product is required to ensure that a given

number-419

once-used ('nonce') value will only occur once during the operational lifetime of

420

the key it is protecting

421

DEV.4.M240: (OpenPGP Protocol ONLY) Provision of encryption and digital signing 422

capability 423

This mitigation is required to counter compatibility failure due to supporting only 424

signing or only encryption 425

At Foundation Grade the product is required to provide both encryption and

426

digital signing capability

427

430

431

436

437

DEV.4.M265: Restrict the lifetime of a given long-term private key 438

This mitigation is required to counter key/passphrase being used enough times 439

to significantly increase the chances of a brute-force attack succeeding 440

At Foundation Grade the product is required to constrain the lifetime of all

441

long-term key agreement and digital signing keys to one year

442

I.e. once a year has passed after a key becomes active, the implementation 443

shall then prevent further use of that key for encryption or digital signature 444

generation. 445

DEV.4.M267: Only use approved algorithms to cryptographically protect outgoing 446

emails 447

This mitigation is required to counter exploitation of weak cryptographic 448

algorithm 449

At Foundation Grade the product is required to only use approved algorithms

450

to encrypt and digitally sign outgoing emails (approved algorithms are listed in

451

Interoperability section)

452

DEV.5 - Design >> Key Store 453

DEV.5.M232: Retain expired/revoked keys for message decryption & recovery 454

This mitigation is required to counter loss of asymmetric key required to decrypt, 455

e.g. due to expiry/revocation 456

At Foundation Grade the product is required to retain expired/revoked keys,

457

but ensure that their usage is restricted to just message decryption and digital

458

signature verification

(18)

DEV.5.M256: Long term keys protected from high risk processes 460

This mitigation is required to counter exploitation of unintended information 461

disclosure to leak keys/secrets 462

At Foundation Grade the product is required to use O/S mechanisms, such as

464

user privileges and the O/S certificate store (or other protected certificate

465

store) to ensure that unencrypted private keys cannot be retrieved by a

466

standard user

467

470

471

DEV.5.M259: Prevent export of non-encrypted private keys 474

This mitigation is required to counter recovery of secrets from a lost/stolen 475

device 476

This mitigation is required to counter export of secrets through an available API 477

At Foundation Grade the product is required to prevent the export of long term

478

secrets, such as private keys, through any available API, unless authenticated

479

as a privileged user

480

It is recommended that the product encrypt long term secrets before exporting 481

them (using algorithms given in the Interoperability section). 482

DEV.6 - Design >> Local Traffic Interface 483

DEV.6.M245: Secure red side interface services 484

This mitigation is required to counter exploitation of red side services that are 485

unavailable from the black network interface 486

At Foundation Grade the product is required to identify and enable the

487

securing of red side services

488

Services offered on the red side must be described in the deployment guide 489

with an explanation of the risks of using each service and details of how to 490

mitigate them (e.g. how to disable them). 491

DEV.7 - Design >> Policy 492

DEV.7.M268: Policy to ensure correct application of encryption at gateway 493

This mitigation is required to counter user only partially encrypting email (e.g. 494

email has unencrypted attachment) 495

This mitigation is required to counter user failing to apply encryption to a 496

message that requires confidentiality protection 497

At Foundation Grade the product is required to ensure all email content that

498

requires encryption gets encrypted before being sent over the untrusted

499

network (e.g. Internet)

(19)

DEV.8 - Design >> RNG 501

DEV.8.M138: Employ an approved entropy source 502

This mitigation is required to counter predictable key generation due to a weak 503

entropy source 504

This mitigation is required to counter the prediction of randomly generated 505

values due to a weak entropy source 506

This mitigation is required to counter prediction of randomly generated values 507

due to a weak PRNG 508

At Foundation Grade the product is required to generate random bits using an

509

entropy source whose entropy generation capability is understood

510

The developer must provide a detailed description of the entropy source 511

used, giving evidence that it can generate sufficient entropy for use in the 512

device, including an estimate of entropy per bit. 513

514

If a hardware noise source is used, then the manufacturer's name, the part 515

numbers and details of how this source is integrated into the product must be 516

supplied. If a software entropy source is employed, the API calls used must 517

be provided. Where appropriate, details must be given of how the output of 518

multiple entropy sources are combined. 519

DEV.8.M186: Reseed PRNG as required 520

values due to repeating PRNG output 522

At Foundation Grade the product is required to follow an approved reseeding

523

methodology

524

For more details on a suitable PRNG, please see the Process for Performing 525

Foundation Grade Evaluations. 526

DEV.8.M193: Smooth output of entropy source with approved PRNG 527

entropy source 529

At Foundation Grade the product is required to employ a PRNG of sufficient

534

Security Strength for all random number generation required in the operation

535

of the product

536

(20)

DEV.8.M196: State the Security Strength required for random numbers 539

entropy source 541

At Foundation Grade the product is required to employ an entropy source of

546

sufficient Security Strength for all random number generation required in the

547

operation of the product

548

The developer must state the Security Strength required of their entropy 549

source based on analysis of all random numbers used in the product. At this 550

grade, the Security Strength is likely to be 128 bits for products that do not 551

use elliptic curve cryptography. For elliptic curve-based asymmetric 552

mechanisms it is likely to be 256 bits, and for finite field based asymmetric 553

mechanisms it is likely to be 192 bits. 554

DEV.8.M218: Perform statistical testing of generated entropy prior to smoothing 555

At Foundation Grade the product is required to employ a PRNG of sufficient

560

Security Strength for all random number generation required in the operation

561

of the product

562

567

568

573

574 575

(21)

B. Verification Mitigations

576

VER.M112: (Software Gateway ONLY) Audit permissions on product install 577

This mitigation is required to counter exploitation of a privileged local service 578

At Foundation Grade the evaluator will audit any system permissions and

579

ACLs set or altered by the product during installation to ensure that no

580

changes are made, which would give a standard user the ability to modify any

581

components that run with higher privileges (either product or system provided).

582

VER.M178: Protocol robustness testing 583

This mitigation is required to counter discovery of a vulnerability in the 584

implementation of the protocol 585

At Foundation Grade the evaluator will perform testing using commercial

586

fuzzing tools

587

Fuzz testing is described in more detail in the Process for Performing 588

VER.M216: (Software Gateway ONLY) Verify update mechanism 590

update process 592

At Foundation Grade the evaluator will validate the developer's assertions

593

regarding the suitability and security of their update process

594

The update process must provide a mechanism by which updates can be 595

authenticated before they are applied. 596

The process and any configuration required must be documented within the 597

Security Procedures. 598

VER.M227: (Bespoke Protocol ONLY) Review protocol strength rationale 599

bespoke key exchange or digital signature protocol 601

This mitigation is required to counter exploitation of bespoke protocol 602

vulnerability 603

At Foundation Grade the evaluator will review an analysis of the protocol

604

provided by the developer to ensure it is logical and consistent

605

The developer must also provide the evaluator with a rationale as to why their 606

bespoke email protection protocol provides equivalent security to OpenPGP 607

or S/MIME. This rationale must explain how the cryptographic mechanisms 608

outlined elsewhere in the SC are applied to emails and why the developer 609

believes these provide an equal level of protection to OpenPGP and S/MIME. 610

611

The evaluator must review the developer's analysis and rationale to ensure it 612

is logically consistent. The evaluator is not expected to perform a detailed 613

cryptographic analysis of the protocol - but must ensure that there is a reason 614

to believe the assertions made by the developer about the cryptographic 615

protection provided by the product. 616

VER.1 - Verify >> Decryption 617

VER.1.M147: Evaluation/Cryptocheck 618

This mitigation is required to counter exploitation of flaws in the cryptographic 619

algorithm implementation 620

At Foundation Grade the evaluator will verify correct cryptographic operation of

621

email message decryption functionality

(22)

VER.2 - Verify >> Email Management 623

VER.2.M270: Logging Mechanism Robustness 624

This mitigation is required to counter exploitation of vulnerabilities in the logging 625

mechanism 626

At Foundation Grade the evaluator should test that the product still operates

627

correctly when its log is (a) nearly full and (b) actually full

628

VER.3 - Verify >> Email Message Processing 629

This mitigation is required to counter unencrypted sensitive data leaking into 631

encrypted message payload 632

At Foundation Grade the evaluator will check encoding process does not leak

633

unencrypted red data into any part of the encrypted email message

634

VER.3.M222: Robustness against compression and decompression errors 635

This mitigation is required to counter decompression of corrupted data causing 636

software crash 637

This mitigation is required to counter compression algorithm leaking sensitive 638

data 639

At Foundation Grade the evaluator will check that decompression errors are

640

not fatal and that the compression process will not leak potentially sensitive

641

information

642

VER.4 - Verify >> Encryption 643

This mitigation is required to counter user failing to specify encryption for email 645

when confidentiality required 646

This mitigation is required to counter malware replacing a randomly generated 647

CEK with a fixed pattern 648

This mitigation is required to counter exploitation of a cryptographic algorithm 649

implementation error 650

At Foundation Grade the evaluator will check a user cannot subvert the

651

encryption process

652

The evaluation team should construct an encryption policy within the product 653

and then verify that an internal user cannot trivially create emails which are 654

not subject to these rules. 655

At Foundation Grade the evaluator will ensure all cryptographic algorithms

656

employed for security functionality have been validated as per the

657

"Cryptographic Validation" section in the CPA Foundation Process document

658

VER.4.M264: Prevent application of cryptographic protection using expired keys 659

This mitigation is required to counter key/passphrase validity periods not 660

enforced on new application of key/passphrase 661

At Foundation Grade the evaluator will check expired cryptographic keys

662

cannot be used to generate a new shared secret or digital signature, etc

663

VER.5 - Verify >> Management Interface 664

VER.5.M247: Management protocol robustness testing 665

management interface protocol 667

At Foundation Grade the evaluator will perform testing using commercial

668

fuzzing tools

669

Fuzz testing is described in more detail in the Process for Performing 670

(23)

C. Deployment Mitigations

673

DEP.M102: Address Space Layout Randomisation 674

error 676

At Foundation Grade the deployment is required to enable ASLR in the host

677

Operating System where available

678

DEP.M103: (Software Gateway ONLY) Administrator authorised updates 679

update process 681

At Foundation Grade the deployment is required to confirm the source of

682

updates before they are applied to the system

683

The administrator is required to have authorised the updates before use. If an 684

automatic process is used, the administrator must also configure the product 685

to authenticate updates. 686

The administrator is required to use the update process described within the 687

Security Procedures. 688

DEP.M110: Audit log review 689

error 692

At Foundation Grade the deployment is required to regularly review audit logs

693

for unexpected entries

694

DEP.M164: (Software Gateway ONLY) Operating system verifies signatures 695

This mitigation is required to counter installation of a malicious privileged local 696

service 697

At Foundation Grade the deployment is required to ensure that signature

698

verification is enabled for applications, services and drivers in the host

699

operating system, where available

700

DEP.M169: (Hardware Gateway ONLY) Physical tamper evidence 701

This mitigation is required to counter physical compromise of device 702

This mitigation is required to counter installation of hardware-level malware 703

At Foundation Grade the deployment is required to educate users to regularly

704

check that tamper labels are intact

705

At Foundation Grade the deployment is required to provide administrators with

706

advice on the tamper threat

707

Advice should include looking for possible damage to tamper evident seals. 708

709

In the event of tampering, the event should be reported as soon as possible 710

and the product must be removed from use immediately. Any product that 711

shows evidence of tampering must not be returned to service. 712

At Foundation Grade the deployment is required to place tamper evident seals

713

over access points on product

714

Use tamper evidence (e.g. stickers) to make entry to system internals 715

detectable by physical inspection. Tamper stickers should be uniquely 716

identifiable to prevent an attacker successfully replacing it with a new, 717

undamaged sticker. 718

(24)

DEP.M203: Update product 719

error 722

At Foundation Grade the deployment is required to update to the latest version

723

where possible

724

DEP.M214: (Software Gateway ONLY) User least privilege 725

This mitigation is required to counter taking advantage of existing user privilege 726

At Foundation Grade the deployment is required to ensure all user accounts

727

have the fewest privileges required to enable business functionality

728

DEP.M225: Interaction with user endpoint consistent with good practices for email 729

security 730

This mitigation is required to counter exploitation of bad practice "encouraged" 731

by encrypted email product 732

At Foundation Grade the deployment is required to ensure interactions with

733

user endpoint are consistent with good practices for email security

734

For instance, avoiding requiring the user to retrieve encrypted email content 735

by always clicking a link in a notification email message (user gets into habit 736

of "blindly" clicking the link and then entering credentials to access the email). 737

DEP.M229: All public keys obtained from remote public key server/repository verify to 738

a trusted entity 739

This mitigation is required to counter spoofing of remote public key 740

server/repository 741

This mitigation is required to counter false key data set in remote public key 742

server/repository 743

This mitigation is required to counter exploitation of general vulnerability in 744

remote public key server/repository 745

At Foundation Grade the deployment is required to ensure that where a

746

remote public key server/repository is used, all public keys retrieved from it can

747

be verified back to a trusted key management entity

748

This is an entity (such as a CA) that is trusted by the security domains 749

associated with the encrypted email deployment and which will have signed 750

all the user endpoint public keys stored in the remote public key 751

server/repository. 752

DEP.M236: Use email-aware anti-virus product 753

This mitigation is required to counter malware in infected domain spreading via 754

encrypted email 755

At Foundation Grade the deployment is required to minimise risk of malware

756

transfer through use of the latest email-aware anti-malware software (which is

757

using the latest malware definitions)

758

To be deployed for use by all gateways, desktop clients and mail servers 759

throughout the domain. 760

DEP.M242: Train users in appropriate use of email encryption 761

This mitigation is required to counter user failing to specify encryption for email 762

when confidentiality required 763

This mitigation is required to counter sending a spoof email apparently from 764

another trusted user containing malicious instructions 765

At Foundation Grade the deployment is required to only allow email encryption

766

to be used by users who have been trained in (a) how to use email encryption

767

and (b) good practices for secure email, such as recognising suspicious emails

(25)

DEP.M255: Protect installed equipment 769

device 771

This mitigation is required to counter unauthorised export of secrets through 772

physical interfaces 773

This mitigation is required to counter interception of non-encrypted email by 774

eavesdropper or user endpoint other than intended recipients 775

At Foundation Grade the deployment is required to have the gateway device

776

located in a secure facility (along with any devices hosting the anti-malware

777

product/s used by the gateway)

778

The equipment must be deployed in an appropriately accredited data centre 779

for the protective marking of the data that the device is handling. 780

DEP.M260: Purge all secrets before disposal 781

This mitigation is required to counter recovery of secrets from a 782

decommissioned or recommissioned device 783

At Foundation Grade the deployment is required to ensure all gateway keys

784

and secrets are securely erased during disposal

785

DEP.1 - Deploy >> Account Management 786

DEP.1.M221: Certificates unambiguously identify associated user 787

This mitigation is required to counter impersonation of a valid user to obtain an 790

email encryption certificate 791

At Foundation Grade the deployment is required to ensure that signed

792

certificates are only generated for legitimate users of the email encryption

793

system

794

DEP.1.M234: Immediate revocation of user keys suspected of being compromised 795

This mitigation is required to counter attacker, masquerading as authorised 796

user, sending malware in encrypted payload 797

This mitigation is required to counter attacker gaining access to user endpoint's 798

desktop account to access their encrypted email private key(s) 799

This mitigation is required to counter user endpoint becoming untrusted (e.g. 800

carrying out malicious activities) 801

At Foundation Grade the deployment is required to have processes to revoke

802

any asymmetric key such that it cannot be used to encrypt or generate a

803

signature with immediate effect

804

It must, for instance, be possible for the system administrator(s) to instigate 805

this revocation mechanism in response to a user reporting suspected 806

compromise of their account credentials (after authenticating that the user is 807

who they say). 808

(26)

DEP.1.M235: Comprehensive user encrypted email account management 809

This mitigation is required to counter attacker, masquerading as authorised 810

user, sending malware in encrypted payload 811

This mitigation is required to counter attacker capturing encrypted email 812

account no longer used by user endpoint 813

This mitigation is required to counter user endpoint becoming untrusted (e.g. 814

carrying out malicious activities) 815

This mitigation is required to counter a user's public key being erroneously 816

revoked 817

At Foundation Grade the deployment is required to provide active user account

818

management for the encrypted email system covering enrolment, revocation,

819

reinstatement & deletion

820

The deployment must also ensure that all user endpoint public keys that are 821

stored in a remote public key server/repository are updated according to the 822

state of that user or user's key (e.g. if the user is revoked, the deployment 823

must remove their keys from the public key server/repository). 824

DEP.2 - Deploy >> Administrator Access Control 825

DEP.2.M152: Initial passphrase is changed on first use 826

This mitigation is required to counter use of system default passphrases 827

At Foundation Grade the deployment is required to ensure passphrase is

828

changed on first logon

829

The system must force users to use an initial passphrase once only, i.e. 830

forces the passphrase to change on first logon. 831

832

It is strongly recommended that initial passphrases have a limited lifetime 833

between generation and first use that is as short as is practicable. 834

DEP.2.M180: Provide guidance on passphrase management 835

This mitigation is required to counter a social engineering attack on the 838

administrator 839

This mitigation is required to counter poor passphrase storage 841

At Foundation Grade the deployment should educate administrators about

842

social engineering methods used by attackers

843

At Foundation Grade the deployment is required to provide training to

844

administrators on passphrase management

845

Users should be provided with guidance regarding the secure handling of 846

passphrases which allow access to sensitive systems. Users must be taught 847

never to disclose passphrases, even to their superiors. 848

Users must also be made aware of the risks of using protectively marked 849

devices in public or untrusted areas. Passphrases should not be entered in 850

areas where others could see them being entered. 851

A user must not use passphrases in more than one system. 852

At Foundation Grade the deployment is required to ensure any hardcopies of

853

passphrases are stored securely

(27)

DEP.2.M198: Suitable passphrase length and complexity 855

At Foundation Grade the deployment is required to ensure passwords are at

859

least 8 characters long

860

User generated passphrases are acceptable, but machine generated 861

passphrases should be used where possible. 862

DEP.3 - Deploy >> Email Message Processing 863

DEP.3.M230: (SMIME Protocol ONLY) Availability of infrastructure for revocation 864

checks 865

This mitigation is required to counter a private signing key of a trusted key 868

management entity becoming compromised 869

At Foundation Grade the deployment is required to ensure latest revocation

870

details are available prior to validating a given key

871

DEP.3.M244: Check raw email content for malware 872

This mitigation is required to counter malware in infected domain spreading via 873

encrypted email 874

At Foundation Grade the deployment is required to quarantine incoming and

875

outgoing emails that have been identified as containing malware

876

Apply anti-malware checks immediately prior to encryption and immediately 877

following decryption (or the gateway receiving an unencrypted email from the 878

untrusted network). Note: these checks are not necessarily carried out on the 879

gateway device. 880

DEP.4 - Deploy >> Key Store 881

DEP.4.M257: Plan for recovery from compromise of long term secrets/keys 882

device 884

This mitigation is required to counter exploitation of unintended information 885

disclosure to leak keys/secrets 886

This mitigation is required to counter unauthorised export of secrets through 887

physical interfaces 888

At Foundation Grade the deployment is required to provide secure means to

890

replace compromised long term keys

891

Such as any trusted keys that are used to verify user endpoint key data held 892

in remote public key servers/repositories. 893

(28)

DEP.5 - Deploy >> Local Traffic Interface 894

DEP.5.M254: Secure transfer of non-encrypted emails from gateway to local email 895

server 896

This mitigation is required to counter interception of non-encrypted email by 897

eavesdropper or user endpoint other than intended recipients 898

At Foundation Grade the deployment should use TLS to secure email transfer

899

between gateway and local email server (i.e. use of STARTTLS for SMTP and

900

POP3)

901

Note: Transfer of an email (over the secure link) to the local server must only 902

be initiated after anti-malware checks have been carried out on any non-903

encrypted email content. Similarly all non-encrypted email content received 904

from the email server must be confirmed clear of malware before being 905

processed by the gateway. 906

DEP.6 - Deploy >> Management Interface 907

DEP.6.M248: Restrict access to policy settings 908

This mitigation is required to counter unauthorised modification of policy through 909

privilege escalation 910

At Foundation Grade the deployment is required to ensure that only an

911

authorised administrator can modify the product's policy settings

912

DEP.6.M249: Audit 913

This mitigation is required to counter unauthorised use of privilege to modify 914

policy 915

At Foundation Grade the deployment is required to have its policy modification

916

events recorded and audited, protected from account administrators

917

DEP.6.M250: Role based access control 918

This mitigation is required to counter unauthorised use of privilege to modify 919

policy 920

At Foundation Grade the deployment is required to enforce a separate account

921

for policy management with respect to other host device accounts

922

DEP.6.M251: Restrict access to management interface 923

This mitigation is required to counter exploitation of poorly protected 924

management interface 925

At Foundation Grade the deployment is required to have access to the

926

gateway's management interface via the black network disabled

927

Where required, remote management may still be performed over the 928

encrypted tunnel. 929

DEP.6.M252: Local management authentication 930

At Foundation Grade the deployment is required to enforce management

933

activities to be authenticated via username/passphrase

934

This is intended to include serial console access, etc. 935

DEP.6.M253: Remote management authentication 936

At Foundation Grade the deployment is required to manage the device via one

939

of; SNMPv3 or TLS with username/passphrase, SSH with

940

username/passphrase

941 942

(29)

IV. GLOSSARY

943

23. The following definitions are used in this document: 944

Term Description

ACL Access Control List

API Application Programmer Interface

ASN.1 Abstract Syntax Notation - notation describing data structures representing data and defining how it is encoded

ASLR Address Space Layout Randomisation ASCII Armor [See Radix-64]

AV Anti-virus

BCC Blind Carbon Copy

BER Basic Encoding Rules - used for ASN.1 encodings BLACK Network Unsecured and untrustworthy network.

CA Certification Authority - issues certificates within a PKI CBC Cipher Block Chaining

CEK Content Encryption Key - a symmetric key that is used to encrypt user data, such as MIME-encoded email content

Certificate Mechanism to associate cryptographic public keys with a user identities within a PKI, typically authenticated by a trusted third party, such as a CA

Certificate server

[See public key server]

CFB Cipher Feedback

CPA Commercial Product Assurance

CRMF Certificate Request Message Format - described in RFC 4211 DER Distinguished Encoding Rules - a more constrained version of

DER

DH Diffie-Hellman – a key agreement mechanism

DLP Data Loss/Leak Prevention - systems that protect against unauthorised disclosure of sensitive data

DoS Denial of Service

DSA Digital Signature Algorithm

ECDSA Variant of DSA which uses Elliptic curve cryptography ECDH Variant of DH which uses Elliptic curve cryptography Ephemeral Typically refers to a “use-once” cryptographic key

FIPS Federal Information Processing Standard (defined by NIST) Fuzzing, fuzzer Testing technique that provides invalid, unexpected, or random

data to the inputs of an application or device