NETWORK SECURITY ESSENTIALS : APPLICATIONS AND STANDARDS
NETWORK SECURITY ESSENTIALS : APPLICATIONS AND STANDARDS
FOURTH EDITION
William Stallings
Chapter 1 Introduction
Chapter 2 Symmetric Encryption and Message Confidentiality
2.1 SYMMETRIC ENCRYPTION PRINCIPLES
2.2 Symmetric Block Encryption Algorithms
2.3 Random and Pseudorandom Numbers
2.4 Stream Ciphers and RC4
2.5 Cipher Block Modes of Operation
Chapter 3 Public-Key Cryptography and Message Authentication
Approaches to Message Authentication
Secure Hash Functions
Message Authentication Codes
Public-Key Cryptography Principles
Public-Key Cryptography Algorithms
Digital Signatures
Chapter 4 Key Distribution and User Authentication
Chapter 5 Transport-Level Security
KEY POINTS:
- Secure Socket Layer (SSL) provides security services between TCP and applications that use TCP. The Internet standard version is called Transport Layer Service (TLS).
- SSL/TLS provides confidentiality using symmetric encryption and message integrity using a message authentication code.
- SSL/TLS includes protocol mechanisms to enable two TCP users to determine the security mechanisms and services they will use.
- HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL to implement secure communication between a Web browser and a Web server.
- Secure Shell (SSH) provides secure remote logon and other secure client/server facilities.
5.1 WEB SECURITY CONSIDERATIONS
Web Security Threats,| Threats | Consequences | Countermeasures | |
| Integrity | • Modification of user data • Trojan horse browser • Modification of memory • Modification of message traffic in transit | • Loss of information • Compromise of machine • Vulnerabilty to all other threats | Cryptographic checksums |
| Confidentiality | • Eavesdropping on the net • Theft of info from server • Theft of data from client • Info about network configuration • Info about which client talks to server | • Loss of information • Loss of privacy | Encryption, Web proxies |
| Denial of Service | • Killing of user threads • Flooding machine with bogus requests • Filling up disk or memory • Isolating machine by DNS attacks | • Disruptive • Annoying • Prevent user from getting work done | Difficult to prevent |
| Authentication | • Impersonation of legitimate users • Data forgery | • Misrepresentation of user • Belief that false information is valid | Cryptographic techniques |
5.2 SECURE SOCKET LAYER(SSL) AND TRANSPORT LAYER SECURITY(TLS)
SSL is designed to make use of TCP to provide a reliable end-to-end secure service. SSL is composed of two layers of protocols:- SSL Record Protocol This provides basic security services to various higher-layer protocols.
- SSL higher-layer protocols These SSL-specific protocols are used in the management of SSL exchange.
- Handshake Protocol
- Change Cipher Spec Protocol
- Alert Protocol
- HTTP
SSL Architecture
- SSL session An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters which can be shared among multiple connections.
- SSL connection The connections are transient. Every connection is associated with one session. A connection is a transport service.
SSL Record Protocol
This provides two services for SSL connections:- Confidentiality A shared secret key is defined and used for the encryption of SSL payloads.
- Message Integrity A shared secret key is defined and used to form a message authentication code (MAC).
- fragmentation Each upper-layer message is fragmented into blocks of a size <= 2 ^14 bytes (16384 bytes)
- compression Optional. Default is NULL for SSLv3/TLS.
- message authentication code A shared secret key is used during the generation of the MAC.The SSLv3 MAC algorithm is based on the original Internet draft for HMAC.
- encryption The compressed(optional) message plus the MAC are encrypted using symmetric encryption.
- header A 5 bytes header is composed of the following fields:
- Type (8 bits) The higher-layer protocol used to process the enclosed fragment.
- Handshake (22, 0x16)
- Change Cipher Spec (20, 0x14)
- Alert (21, 0x15)
- Application Data (23, 0x17)
- Major Version (8 bits) For SSLv3, the value is 3.
- Minor Version (8 bits) For SSLv3, the value is 0.
- Length (16 bits) The length in bytes of the plaintext(optionally compressed)
SSL Change Cipher Spec(CCS) Protocol
This protocol consists of a single byte with the value 1. It is normally used as part of the handshake process to switch to use symmetric key encryption for subsequent SSL records. The change cipher spec message is normally sent at the end of the SSL handshake. CCS records are used in order to indicate a change in cryptographic ciphers. Immediately after the CCS record, all data is encrypted with the new cipher. CCS records might or might not be encrypted; in a simple connection with a single handshake, the CCS record is not encrypted: 5 bytes SSL record header + 1 byte CCS payload).Alert Protocol
Alert records are used in order to indicate to the peer that a condition has occured. Some alerts are warnings, while others are fatal and cause the connection to fail. Alerts might or might not be encrypted, and might occur during a handshake or during data transfer. The primary job of the Alert Protocol in SSL is to inform the other end about the issues(if any), in the current session. Each message in this protocol consists of two bytes:- severity The value 1 is for warning , 2 is for fatal. If the level is fatal, SSL immediately terminates the connection. If an alert with a level of warning is received, the receiving party may decide at its discretion whether to treat this as a fatal error or not.
- description A value that indicates the specific alert.
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
The description of values can be found in RFC2246 "7.2. Alert protocol". Handshake Protocol
This protocol allows the server and client to- authenticate each other
- negotiate an encryption and MAC algorithm and cryptographic keys used to protect data sent in an SSL record.
- Type 1 byte. The type of the message:
- Length 3 bytes. The length of the message in bytes.
- Content The parameters associated with this message
- hello_request null
- client_hello
- version The highest SSL version understood by the client.
- random a 32-bit timestamp and 28 bytes random number. These values serve as nonces and are used during key exchange.
- session id A variable-length session identifier. A nonzero value indicates that the client wishes to update the parameters of an existing connection or to create a new connection on this session. A zero value indicates that the client wishes to establish a new connection on a new session.
- cipher suite a list of cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec. key exchange algorithm is one of the following:
- RSA: The secret key is encrypted with the receiver’s RSA public key.
- Fixed Diffie-Hellman the server's public-key certificate contains the Diffie-Hellman public-key parameters. The client provides its Diffie-Hellman public-key parameters. This method results in a fixed secret key generated and used between two peers.
- Ephemeral(短暫的) Diffie-Hellman the Diffie-Hellman public keys are exchanged, signed using the sender’s private RSA or DSS key. Certificates are needed and used to authenticate the public keys.
- Anonymous Diffie-Hellman each side sends its public Diffie-Hellman parameters to the other with no authentication. The receiver can use the corresponding public key in sender's public certificate to verify the signature.
- Fortezza the Fortezza scheme.
- CipherAlgorithm RC4, RC2, DES, 3DES, DES40, IDEA, or Fortezza
- MACAlgorithm MD5 or SHA-1
- CipherType Stream or Block
- IsExportable True or False
- HashSize 0, 16 (for MD5), or 20 (for SHA-1) bytes
- Key Material A sequence of bytes that contain data used in generating the write keys
- IV Size The size of the Initialization Value for Cipher Block Chaining (CBC) encryption
- compression method
- server_hello
- version The Version field contains the lower of the versions suggested by the client and the highest supported by the server.
- random generated by the server and is independent of the client’s random field.
- session id If the SessionID field is not the same value as the client; the server’s SessionID field contains the value for a new session.
- cipher suite the single cipher suite selected by the server from those proposed by the client.
- compression method
- certificate one or a chain of X.509v3 certificates. The certificate message is required for any agreed-on key exchange method except anonymous Diffie-Hellman.
- server_key_exchange The Server may create and send a temporary key to the Client using server_key_exchange message. This key can be used by the Client to encrypt the Client Key Exchange message. This step is required only when the Server Certificate does not contain a Server Public Key.It is used for anonymous Diffie-Hellman, Diffie-Hellman Ephemeral and Ephemeral RSA Key-Exchange methods. This includes fields:
- parameters
- signature
- certificate_request A non-anonymous server (server not using anonymous Diffie-Hellman) can request a certificate from the client. The certificate_request message includes two parameters:
- certificate_type The certificate type indicates the public-key algorithm and its use:
• RSA, signature only • DSS, signature only • RSA for fixed Diffie-Hellman; in this case the signature is used only for authentication, by sending a certificate signed with RSA • DSS for fixed Diffie-Hellman; again, used only for authentication • RSA for ephemeral Diffie-Hellman • DSS for ephemeral Diffie-Hellman • Fortezza
- algorithm
- signature A digital signature using the algorithm over the contents. The length of the signature is specified by the signing algorithm and key.
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
- master_secret
- finished_label
- Hash(handshake_messages)
The steps during the Handshake Protocol phase, - Hello Phase
- The exchange is initiated by the client, which sends a client_hello message After sending the client_hello message, the client waits for the server_hello message
- The Server responds with server_hello message The highest protocol version that is supported by the Client and the Server is sent back.
- Authentication and Server's Public Key Exchange In this phase, the Client and the Server generates an authenticated shared secret, called pre_master secret, which is converted to master sercret. SSLv3 and TLS support RSA and Diffie-Hellman for key exchange.
- The Server sends its certificate to the Client. The Server certificate contains the Server's Public key. The Client will use this key to authenticate the Server and to encrypt the pre_master secret. pre-master secret是一個 46 個位元組的亂數，用來產生對稱加密金鑰以及訊息鑑定碼(MAC)金鑰. The pre_master secret has two pieces:
- the Client's protocol version
- the random number
- The Server may create and send a temporary key to the Client using the server_key_exchange message. This step is required only when the Server Certificate does not contain a Server Public Key.
- The Server may request authentication from the Client using certificate_request message.
- After these messages, the Server sends a server_done message indicating it has finished and is awaiting a response from the Client.
- Client Authentication and Key Derivation Upon receipt of the server_done message, the client should verify that the server provided a valid certificate (if required) and check that the server_hello parameters are acceptable. If all is satisfactory, the client sends one or more messages back to the server. 用戶端會使用一系列的加密作業， 將 pre-master secret 轉換為 master secret， 以便用來產生執行加密以及訊息鑑定所需要的所有金鑰資料。 之後用戶端會傳送一則 『變更密碼規格』 訊息到伺服器， 使伺服器切換到剛剛協議好的密碼套件。由用戶端傳送的下一則 訊息（『完成』 訊息）將會是以此密碼方法和金鑰加密的第一則訊息。
- If the server has requested a certificate, the client begins this phase by sending
a certificate and certificate_verify message. If no suitable certificate is available, the client sends a no_certificate alert instead, the server might respond with a fatal handshake failure alert if client authentication is required.
It does the job of Client authentication.
- The Client sends the client_key_exchange message after computing the pre_master secret. For pre_master_secret exchange, there are 2 key exchange possibilities:
- RSA A 48-byte pre_master_secret is generated by the client, encrypted with the server’s public RSA key, and sent to the server.
- Diffie-Hellman Both client and server generate a Diffie-Hellman public key. After these are exchanged, each side performs the Diffie-Hellman calculation to create the shared pre_master_secret.
- change_cipher_spec The Client then sends a change_cipher_spec message indicating to the Server that all messages that follow the Client's finished message.
- The client then immediately sends the finished message under the new algorithms, keys, and secrets. A finished message is always sent immediately after a change_cipher_spec message in order to verify that the key exchange and authentication processes were successful.
- The server sends its own change_cipher_spec message, transfers the pending to the current CipherSpec, and sends its finished message. At this point, the handshake is complete and the client and server may begin to exchange application-layer data.
master_secret = MD5(pre_master_secret || SHA('A' ||
pre_master_secret || ClientHello.random ||
ServerHello.random)) ||
MD5(pre_master_secret || SHA('BB' ||
pre_master_secret || ClientHello.random ||
ServerHello.random)) ||
MD5(pre_master_secret || SHA('CCC' ||
pre_master_secret || ClientHello.random ||
ServerHello.random))
where ClientHello.random and ServerHello.random are the two nonce values exchanged in the initial hello messages.
5.3 TRANSPORT LAYER SECURITY
5.4 HTTPS
HTTPS (HTTP over SSL) refers to the combination of HTTP and SSL. HTTPS is documented in RFC 2818, HTTP Over TLS. A normal HTTP connection uses port 80. If HTTPS is specified, port 443 is used, which invokes SSL.- Connection Initiation For HTTPS, the agent acting as the HTTP client also acts as the TLS client. When the TLS handshake has finished, the client may then initiate the first HTTP request. All HTTP data is to besent as TLS application data. At the level of TLS, a session is established between a TLS client and a TLS server. This session can support one or more connections at any time.
- Connection Closure At the TLS level, the proper way to close a connection is for each side to use the TLS alert protocol to send a close_notify alert. HTTP clients also must be able to cope with a situation in which the underlying TCP connection is terminated without a prior close_notify alert and without a Connection: close indicator.
5.5 SECURE SHELL (SSH)
The SSH protocol (also referred to as Secure Shell) is a method for secure remote login from one computer to another.- The protocol works in the client-server model, which means that the connection is established by the SSH client connecting to the SSH server. The SSH client drives the connection setup process and uses public key cryptography to verify the identity of the SSH server.
- After the setup phase the SSH protocol uses strong symmetric encryption and hashing algorithms to ensure the privacy and integrity of the data that is exchanged between the client and server.
SSH is organized as three protocols that typically run on top of TCP: 
- Transport Layer Protocol Provides server authentication, data confidentiality, and data integrity with forward secrecy. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream.
- User Authentication Protocol Authenticates the client-side user to the server.It runs over the transport layer protocol.
- Connection Protocol Multiplexes multiple logical communications channels over a single, underlying SSH connection. It runs over the user authentication protocol.
The Secure Shell (SSH) Transport Layer Protocol(RFC 4253)
The sequence of events in the SSH Transport Layer Protocol.
- The client initiates the TCP connection.
- When the connection has been established, both sides MUST send an identification string With the format:
SSH-protoversion-softwareversion SP comments CR LF
byte SSH_MSG_KEXINIT
byte[16] cookie (random bytes)
name-list kex_algorithms
name-list server_host_key_algorithms
name-list encryption_algorithms_client_to_server
name-list encryption_algorithms_server_to_client
name-list mac_algorithms_client_to_server
name-list mac_algorithms_server_to_client
name-list compression_algorithms_client_to_server
name-list compression_algorithms_server_to_client
name-list languages_client_to_server
name-list languages_server_to_client
boolean first_kex_packet_follows
uint32 0 (reserved for future extension)
Each of the algorithm name-lists MUST be a comma-separated list of algorithm names in the order of preference. Data integrity is protected by including with each packet a MAC that is computed from (a shared secret, packet sequence number, and the contents of the packet). The message authentication algorithm and key are negotiated during key exchange. The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. The end of key exchange is signaled by the exchange of SSH_MSG_NEWKEYS packets. byte SSH_MSG_NEWKEYSThis message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms.
byte SSH_MSG_SERVICE_REQUEST
string service name
If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
byte SSH_MSG_SERVICE_ACCEPT
string service name
Note that after a key exchange with implicit server authentication, the client MUST wait for a response to its service request message before sending any further data. User Authentication Protocol(RFC 4252)
The User Authentication Protocol provides the means by which the client is authenticated to the server. The server drives the authentication by telling the client which authentication methods can be used, the client has the freedom to try the methods listed by the server in any order.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fields
where - user name the authorization identity the client is claiming,
- service name the facility to which the client is requesting access (typically the SSHConnection Protocol)
- method name the authentication method being used in this request. The following 'method name' values are defined.
- "publickey" This method works by sending a signature signed by a private key of the user. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the "publickey" method would be acceptable.
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string "publickey"
boolean FALSE
string public key algorithm name
string public key blob
The server MUST respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following:
byte SSH_MSG_USERAUTH_PK_OK
string public key algorithm name from the request
string public key blob from the request
To perform actual authentication, the client MAY then send a signature generated using the private key
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
string signature
The value of 'signature' is a signature by the corresponding private key over the following data
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "password"
boolean FALSE
string plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
留言