NIST SP800-52r2草案：TLS实施指南与联邦信息安全标准

需积分: 9 188 浏览量更新于2024-07-16 收藏 624KB PDF 举报

NIST SP800-52r2-draft2是美国国家标准与技术研究院(National Institute of Standards and Technology, NIST)发布的第二版草案指南，主要关注的是Transport Layer Security (TLS)的选型、配置和使用。TLS是一种广泛应用于网络通信的安全协议，它在可靠的传输协议如Transmission Control Protocol (TCP)基础上运行，为诸如金融交易、医疗记录访问、电子邮件等敏感或有价值的在线服务提供保护，确保数据隐私和完整性。在2018年10月发布的这份文档中，NIST强调了以下关键知识点： 1. **目的与背景**：该指南是为了根据2014年的《联邦信息安全现代化法案》(Federal Information Security Modernization Act, FISMA)制定，以确保所有公开可访问的联邦网站和服务仅通过安全连接提供服务，从而提升用户隐私并防止数据在传输过程中被篡改。 2. **协议结构**：TLS作为应用层协议，独立于特定的应用程序，如HTTP和IMAP，它提供了一个加密通道，使两个通信应用程序（如浏览器和服务器）能够在网络上通过应用协议安全地传输数据。 3. **选择与配置**：指南提供了关于如何选择适合的TLS实现，以及如何配置这些实施的详细建议，这包括考虑的因素如版本兼容性、加密算法强度、证书管理、握手过程的安全性和性能指标等。 4. **责任与授权**：NIST负责根据FISMA制定的信息安全标准和指导方针，确保政府机构遵循最低安全要求，并促进整个行业的最佳实践。 5. **适用范围**：这份指南适用于任何处理敏感信息的网络服务提供商，特别是涉及个人可识别信息(PII)、财务数据和登录凭证的服务，以确保数据传输过程中的安全性。 6. **合规性要求**：对于联邦机构而言，按照M-15-132备忘录，必须强制使用安全连接来保护公众访问的网站和web服务。通过遵循NIST SP800-52r2-draft2中的指导，组织和个人可以确保他们的网络通信符合最新的信息安全标准，降低数据泄露和攻击的风险，同时提高用户对网络服务的信任度。

NIST SP 800-52 REV. 2 (2ND DRAFT) GUIDELINES FOR TLS IMPLEMENTATIONS

altered to treat a padding error as a bad message authentication code, rather than a decryption 286

failure. In addition, the TLS 1.1 RFC acknowledges attacks on CBC mode that rely on the time 287

to compute the message authentication code (MAC). The TLS 1.1 specification states that to 288

defend against such attacks, an implementation must process records in the same manner 289

regardless of whether padding errors exist. Further implementation considerations for CBC 290

modes (which were not included in RFC 4346 [23]) are discussed in Section 3.3.2. 291

TLS 1.2, specified in RFC 5246 [24], made several cryptographic enhancements, particularly in 292

the area of hash functions, with the ability to use or specify the SHA-2 family algorithms for 293

hash, MAC, and Pseudorandom Function (PRF) computations. TLS 1.2 also adds authenticated 294

encryption with associated data (AEAD) cipher suites. 295

TLS 1.3, specified in RFC 8446 [50], represents a significant change to TLS that aims to address 296

threats that have arisen over the years. Among the changes are a new handshake protocol, a new 297

key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function 298

(HKDF) [36], and the removal of cipher suites that use static RSA or DH key exchanges, the 299

CBC mode of operation, or SHA-1. Many extensions defined for use with TLS 1.2 and below 300

cannot be used with TLS 1.3. 301

1.2 Scope 302

Security is not a single property possessed by a single protocol. Rather, security includes a 303

complex set of related properties that together provide the required information assurance 304

characteristics and information protection services. Security requirements are usually derived 305

from a risk assessment of the threats or attacks that an adversary is likely to mount against a 306

system. The adversary is likely to take advantage of implementation vulnerabilities found in 307

many system components, including computer operating systems, application software systems, 308

and the computer networks that interconnect them. Thus, in order to secure a system against a 309

myriad of threats, security must be judiciously placed in the various systems and network layers. 310

These guidelines focus only on network security, and they focus directly on the small portion of 311

the network communications stack that is referred to as the transport layer. Several other NIST 312

publications address security requirements in the other parts of the system and network layers. 313

Adherence to these guidelines only protects the data in transit. Other applicable NIST standards 314

and guidelines should be used to ensure protection of systems and stored data. 315

These guidelines focus on the common use cases where clients and servers must interoperate 316

with a wide variety of implementations, and authentication is performed using public-key 317

certificates. To promote interoperability, implementations often support a wide array of 318

cryptographic options. However, there are much more constrained TLS implementations where 319

security is needed but broad interoperability is not required, and the cost of implementing unused 320

features may be prohibitive. For example, minimal servers are often implemented in embedded 321

controllers and network infrastructure devices such as routers, and then used with browsers to 322

remotely configure and manage the devices. There are also cases where both the client and server 323

for an application’s TLS connection are under the control of the same entity, and therefore 324

allowing a variety of options for interoperability is not necessary. The use of an appropriate 325

subset of the capabilities specified in these guidelines may be acceptable in such cases. 326

NIST SP 800-52 REV. 2 (2ND DRAFT) GUIDELINES FOR TLS IMPLEMENTATIONS

2 TLS Overview 350

TLS exchanges records via the TLS record protocol. A TLS record contains several fields, 351

including version information, application protocol data, and the higher-level protocol used to 352

process the application data. TLS protects the application data by using a set of cryptographic 353

algorithms to ensure the confidentiality, integrity, and authenticity of exchanged application data. 354

TLS defines several protocols for connection management that sit on top of the record protocol, 355

where each protocol has its own record type. These protocols, discussed in Section 2.1, are used 356

to establish and change security parameters, and to communicate error and warning conditions to 357

the server and client. Sections 2.2 through 2.6 describe the security services provided by the TLS 358

protocol and how those security services are provisioned. Section 2.7 discusses key management. 359

2.1 TLS Subprotocols 360

There are three subprotocols in the TLS protocol that are used to control the session connection: 361

the handshake, change cipher spec, and alert protocols. The TLS handshake protocol is used to 362

negotiate the session parameters. The alert protocol is used to notify the other party of an error 363

condition. The change cipher spec protocol is used in TLS 1.0, 1.1, and 1.2 to change the 364

cryptographic parameters of a session. In addition, the client and the server exchange application 365

data that is protected by the security services provisioned by the negotiated cipher suite. These 366

security services are negotiated and established with the handshake. 367

The handshake protocol consists of a series of message exchanges between the client and the 368

server. The handshake protocol initializes both the client and server to use cryptographic 369

capabilities by negotiating a cipher suite of algorithms and functions, including key 370

establishment, digital signature, confidentiality and integrity algorithms. Clients and servers can 371

be configured so that one or more of the following security services are negotiated during the 372

handshake: confidentiality, message integrity, authentication, and replay protection. A 373

confidentiality service provides assurance that data is kept secret, preventing eavesdropping. A 374

message integrity service provides confirmation that unauthorized data modification is detected, 375

thus preventing undetected deletion, addition, or modification of data. An authentication service 376

provides assurance of the sender or receiver’s identity, thereby detecting forgery. Replay 377

protection ensures that an unauthorized user does not capture and successfully replay previous 378

data. In order to comply with these guidelines, both the client and the server must be configured 379

for data confidentiality and integrity services. 380

The handshake protocol is used to optionally exchange X.509 public-key certificates

to 381

authenticate the server and the client to each other. 382

The handshake protocol is responsible for establishing the session parameters. The client and 383

server negotiate algorithms for authentication, confidentiality and integrity, as well as derive 384

symmetric keys and establish other session parameters, such as extensions. The negotiated set of 385

cryptographic algorithms is called the cipher suite. 386

In these guidelines, the terms “certificate” and “public-key certificate” are used interchangeably.

NIST SP 800-52 REV. 2 (2ND DRAFT) GUIDELINES FOR TLS IMPLEMENTATIONS

Alerts are used to convey information about the session, such as errors or warnings. For example, 387

an alert can be used to signal a decryption error (decrypt_error) or that access has been denied 388

(access_denied). Some alerts are used for warnings, and others are considered fatal and lead to 389

immediate termination of the session. A close_notify alert message is used to signal normal 390

termination of a session. Like all other messages after the handshake protocol is completed, alert 391

messages are encrypted (and optionally compressed in TLS versions prior to TLS 1.3). 392

Details of the handshake, change cipher spec (in TLS versions prior to 1.3), and alert protocols 393

are outside the scope of these guidelines; they are described in RFC 5246 [24] and RFC 8446 394

[50]. 395

2.2 Shared Secret Negotiation 396

The client and server establish keying material during the TLS handshake protocol. The 397

derivation of the premaster secret depends on the key exchange method that is agreed upon and 398

the version of TLS used. For example, when Diffie-Hellman is used as the key-exchange 399

algorithm in TLS 1.2 and earlier versions, the client and server send each other their parameters, 400

which are used to compute the premaster secret. The premaster secret, along with random values 401

exchanged by the client and server in the hello messages, is used in a pseudorandom function 402

(PRF) to compute the master secret. In TLS 1.3, the master secret is derived by iteratively 403

invoking an extract-then-expand function with previously derived secrets. The master secret is 404

used to derive session keys, which are used by the negotiated security services to protect the data 405

exchanged between the client and the server, thus providing a secure channel for the client and 406

the server to communicate. 407

The establishment of these secrets is secure against eavesdroppers. When the TLS protocol is 408

used in accordance with these guidelines, the application data, as well as the secrets, are not 409

vulnerable to attackers who place themselves in the middle of the connection. The attacker 410

cannot modify the handshake messages without being detected by the client and the server 411

because the Finished message, which is exchanged after security parameter establishment, 412

provides integrity protection to the entire exchange. In other words, an attacker cannot modify or 413

downgrade the security of the connection by placing itself in the middle of the negotiation. 414

2.3 Confidentiality 415

Confidentiality is provided for a communication session by the negotiated encryption algorithm 416

for the cipher suite and the encryption keys derived from the master secret and random values, 417

one for encryption by the client (the client write key), and another for encryption by the server 418

(the server write key). The sender of a message (client or server) encrypts the message using a 419

derived encryption key; the receiver uses the same (independently derived) key to decrypt the 420

message. Both the client and server know these keys, and decrypt the messages using the same 421

key that was used for encryption. The encryption keys are derived from the shared master secret. 422

2.4 Integrity 423

The keyed MAC algorithm, specified by the negotiated cipher suite, provides message integrity. 424

As with confidentiality, there is a different key for each direction of communication. The sender 425

of a message (client or server) calculates the MAC for the message using the appropriate MAC 426

剩余70页未读，继续阅读

艾米的爸爸

粉丝: 800
资源: 314

NIST SP800-52r2草案：TLS实施指南与联邦信息安全标准

NIST SP800-53安全控制措施标准中英文版发布

源代码解读：NIST SP800-90B 随机数熵评估标准

Matlab实现NIST SP800-90B统计测试方法

NIST SP800-160-vol2-draft.pdf

NIST SP800-71-draft.pdf

NIST SP800-38Gr1-draft.pdf

NIST SP800-133r1-draft.pdf

NIST SP800-175Br1-draft.pdf

NIST SP800-81-2.pdf

NIST SP800-76-2.pdf

最新资源