Network Security

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a security enhancement to the MIME Internet e-mail format standard, based on RSA technology. It provides authentication, message integrity and non-repudiation of origin (digital signature) and confidentiality (encryption) for MIME data. It defines new content types (e.g. application/pkcs7-mime, multipart/signed) and uses X.509 certificates issued by a certification authority for public keys. Typical algorithms are SHA-256 for hashing, RSA (or DSA/ECDSA) for signatures, and AES (or 3DES) for content encryption, with RSA or Diffie-Hellman for key exchange.

Functional flow (simplified S/MIME)

The services are: enveloped data (encrypted content plus encrypted content-encryption key), signed data (message plus encrypted digest), and a combination of both.

Sender side: sign and then encrypt

1. The sender prepares the MIME message $M$.
2. A hash code $H(M)$ is calculated using SHA-256.
3. The hash is encrypted with the sender's private key $KR_a$, giving the signature $S = E(KR_a, H(M))$.
4. The message and signature (with the sender's certificate) are packed as a SignedData object (MIME type multipart/signed or application/pkcs7-mime; smime-type=signed-data).
5. A random one-time session key $K_s$ is generated.
6. The signed block is encrypted with $K_s$ using a symmetric algorithm (AES): $C = E(K_s, M \| S)$.
7. $K_s$ is encrypted with the receiver's public key $KU_b$: $E(KU_b, K_s)$.
8. The encrypted key and ciphertext form an EnvelopedData object, which is base64 (radix-64) encoded for transport over SMTP.

Receiver side: decrypt and then verify

1. The receiver converts the radix-64 data back to binary.
2. The encrypted session key is decrypted with the receiver's private key $KR_b$: $K_s = D(KR_b, E(KU_b, K_s))$.
3. The ciphertext is decrypted with $K_s$ to recover $M \| S$.
4. The signature $S$ is decrypted with the sender's public key $KU_a$ (from the certificate) to get the received hash $H'$.
5. The receiver computes the hash of the received message $H(M)$ itself.
6. If the two hashes are equal, the message is authentic and unaltered and the sender cannot deny sending it; otherwise it is rejected.

Thus confidentiality is given by the session key encryption, and authentication, integrity and non-repudiation by the signature.

Mobile device security: features to consider

Mobile devices (phones, tablets) store personal and corporate data and connect over many networks, so the following need to be considered.

1. Device security. Strong screen lock (PIN, password, biometrics), automatic lock timeout, full-device or file-based encryption, remote wipe and device tracking in case of loss or theft, and disabling jailbreak/rooting.
2. Traffic security. Use of SSL/TLS, HTTPS and VPN (IPsec/SSL VPN) for all traffic, WPA2/WPA3 for Wi-Fi, and care with public hotspots and Bluetooth/NFC.
3. Barrier security / application security. Install apps only from trusted stores, apply the permission model with least privilege, sandboxing of apps, application whitelisting/blacklisting, and antimalware.
4. Update and patch management. Timely OS and application updates to close vulnerabilities.
5. Mobile device management (MDM) and policies. Enforce BYOD policy, containerisation of corporate data, remote configuration, and separation of personal and work data.
6. Authentication and access control. Multi-factor authentication, secure access to enterprise resources, and certificates for device identity.
7. Backup and data loss prevention. Regular secure backup and control of data leaving the device.

Internet Key Exchange (IKE)

IKE is the protocol used in IPsec to automatically negotiate security associations (SAs) and establish shared secret keys between two peers, so keys need not be manually configured. It is based on ISAKMP (framework) and the Oakley key determination protocol (Diffie-Hellman). It runs over UDP port 500.

How IKE works (IKEv2 summary)

1. IKE_SA_INIT (first exchange). The initiator sends its proposed cryptographic algorithms (encryption, integrity, DH group), its Diffie-Hellman public value $g^i \bmod p$, and a nonce $N_i$. The responder selects algorithms and replies with its own DH value $g^r \bmod p$ and nonce $N_r$. Both compute the shared secret $g^{ir} \bmod p$ and derive keys (SKEYSEED) for encrypting and authenticating the rest of the exchange. This creates the IKE SA.
2. IKE_AUTH (second exchange). Encrypted under the IKE SA, each side sends its identity, a certificate (optional) and an AUTH payload (signature or pre-shared-key MAC) proving it holds the private key or secret. They also negotiate the first child SA (traffic selectors and ESP/AH proposals). This gives mutual authentication.
3. CREATE_CHILD_SA. Used to create additional IPsec SAs or to rekey existing SAs, optionally with a fresh DH exchange for perfect forward secrecy.
4. INFORMATIONAL. Used for deleting SAs, error notifications and liveness checks.

In IKEv1 the same is achieved by Phase 1 (main mode with six messages or aggressive mode with three, producing the ISAKMP SA) and Phase 2 (quick mode, producing IPsec SAs). The keys derived are then used by AH/ESP to protect data.

Gateway security in IoT

An IoT gateway is the device that connects constrained IoT devices (sensors, actuators) to the Internet or cloud. It aggregates data, translates between protocols (e.g. Zigbee, BLE, LoRa to MQTT/HTTP over IP), and often performs local processing. Gateway security means protecting this device and the traffic through it. Its functions are:

• Secure and authenticate devices that connect to it (device identity, certificates, pre-shared keys) and refuse unknown ones.
• Provide encryption (TLS/DTLS, VPN) for the link to the cloud, since many constrained devices cannot support strong cryptography themselves.
• Firewalling, filtering, intrusion detection and rate limiting between the local network and the Internet.
• Secure boot, signed firmware, remote update and key storage (TPM/secure element) on the gateway.
• Access control, logging and monitoring, and isolation of device segments.

The gateway is a single point of failure, so if it is compromised all devices behind it are exposed.

IoT security environment

The IoT environment can be described in layers, each with its own security needs.

1. Devices (things). Constrained in memory, CPU and power, often unattended and physically accessible. They need secure boot, tamper resistance, unique identity and a secure update mechanism.
2. Communication/network. Short-range and wireless links (Zigbee, BLE, Wi-Fi, 6LoWPAN) are open to eavesdropping, replay and jamming. They need link-layer encryption and lightweight protocols such as DTLS.
3. Gateway / edge. Protocol conversion, local security enforcement as described above.
4. Cloud / back end and applications. Data storage and analytics, requiring authentication, authorisation (API security), data encryption and privacy controls.
5. Users and management. Device provisioning, key management, patch management and monitoring.

Typical threats are unauthorised access, firmware tampering, botnets (e.g. Mirai), data theft and privacy violations, denial of service, and man-in-the-middle attacks. Countermeasures follow the principles of confidentiality, integrity, availability and authentication at each layer, together with lifecycle management from manufacture to disposal.

Security standards provide agreed requirements, best practices and frameworks so that security can be implemented consistently and audited. Important ones are:

• ISO/IEC 27001 and 27002. Specify an Information Security Management System (ISMS) and a code of practice with controls (risk assessment, access control, cryptography, incident management). Organisations can be certified.
• NIST standards. NIST SP 800 series, the NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover), FIPS standards such as FIPS 140-3 (cryptographic modules), FIPS 197 (AES) and FIPS 180 (SHA).
• PCI DSS. Payment Card Industry Data Security Standard for organisations that handle card data (firewalls, encryption, access control, monitoring).
• IETF/Internet standards. RFCs such as IPsec (RFC 4301), TLS (RFC 8446), DNSSEC (RFC 4033-4035), S/MIME and SSH.
• IEEE standards. For example IEEE 802.11i (WPA2) for wireless and IEEE 802.1X for port-based network access control.
• ITU-T X.509. Public key certificate format and authentication framework, and X.800 security architecture for OSI.
• COBIT, HIPAA, GDPR, SOX. Governance and regulation-oriented frameworks and laws for IT control, health data privacy and personal data protection.
• Common Criteria (ISO/IEC 15408). Evaluation of the security of IT products into Evaluation Assurance Levels (EAL1 to EAL7).

Following standards ensures interoperability, a minimum baseline of protection, compliance with law, and customer trust.

Mutual authentication with symmetric encryption relies on a trusted third party, a Key Distribution Center (KDC), that shares a master key with each user: $K_a$ with A and $K_b$ with B. The protocol (Needham-Schroeder, with the timestamp or nonce fix against replay) is as follows.

1. A to KDC: $ID_A \,\|\, ID_B \,\|\, N_1$. A requests a session key to talk to B, with a fresh nonce $N_1$.
2. KDC to A: $E(K_a, [K_s \,\|\, ID_B \,\|\, N_1 \,\|\, E(K_b, [K_s \,\|\, ID_A])])$. A decrypts it, checks that $N_1$ and $ID_B$ match (so the reply is fresh and for the intended partner), and obtains the session key $K_s$ and the ticket $E(K_b,[K_s \| ID_A])$.
3. A to B: $E(K_b, [K_s \,\|\, ID_A])$. A forwards the ticket. Only B can decrypt it, so B learns $K_s$ and that it is for A.
4. B to A: $E(K_s, N_2)$. B sends a challenge with a fresh nonce $N_2$ encrypted under $K_s$.
5. A to B: $E(K_s, f(N_2))$, for example $N_2 - 1$. This proves that A holds $K_s$.

Since only A and B (and the KDC) know $K_s$, a correct response to the challenge authenticates each party to the other. Nonces and timestamps prevent replay of old messages, and the session key $K_s$ then also protects the following communication.

Identity federation is the arrangement by which identity information, authentication and attributes of a user are shared across multiple independent organisations (security domains) that trust each other, so that a user authenticated in one domain can access services in another without creating separate accounts. It enables single sign-on (SSO) across domains. Common standards are SAML, OpenID Connect and OAuth 2.0. Its entities are:

• Principal (user) who wants a service.
• Identity provider (IdP) that authenticates the user and issues assertions about identity and attributes.
• Service provider (SP / relying party) that offers the service and trusts the IdP's assertions.
• Attribute service that supplies additional attributes.

Federated identity operation (typical flow)

1. The user requests a resource from the service provider.
2. The service provider finds that the user has no session and redirects the user (with an authentication request) to the IdP, which was agreed in a prior trust relationship.
3. The IdP authenticates the user (password, MFA) if not already logged in.
4. The IdP creates a signed assertion or token (SAML assertion / ID token) holding the user's identity and attributes, and sends it to the SP through the user's browser.
5. The SP verifies the signature and validity (using the IdP's public key from the trust agreement), maps the attributes to local access rights and grants access.
6. For further services in the federation, the existing IdP session allows access without logging in again.

Benefits are single sign-on, fewer passwords, central control of identity, and easier partner collaboration, while the user's credentials are never given to the SP.

A TLS session is created by the handshake protocol and may be shared by many connections. The session state is defined by the following parameters.

• Session identifier. An arbitrary byte sequence chosen by the server to identify an active or resumable session.
• Peer certificate. The X.509v3 certificate of the peer; may be null.
• Compression method. The algorithm used to compress data before encryption.
• Cipher spec. The bulk data encryption algorithm (null, AES, 3DES etc.) and the hash algorithm for the MAC (e.g. SHA), with attributes such as hash size.
• Master secret. A 48-byte secret shared between client and server, from which the keys are derived.
• Is resumable. A flag showing whether the session may be used to start new connections (session resumption without a full handshake).

A connection state in addition has server and client random values, server write MAC secret, client write MAC secret, server and client write keys, initialisation vectors and sequence numbers.

The TLS handshake protocol allows the client and server to authenticate each other, negotiate the encryption and MAC algorithms and cryptographic keys before any application data is sent. It has four phases.

Phase 1: Establish security capabilities

• client_hello: client version, 32-byte random number, session ID, list of supported cipher suites (key exchange and cipher), and compression methods.
• server_hello: the chosen version, server random, session ID, and the selected cipher suite and compression method.

Phase 2: Server authentication and key exchange

• The server sends its Certificate (X.509 chain), unless anonymous key exchange is used.
• server_key_exchange (for ephemeral DH or when the certificate cannot be used for key exchange), which is signed by the server.
• Optionally certificate_request if client authentication is needed.
• server_hello_done to mark the end of this phase.

Phase 3: Client authentication and key exchange

• The client sends its Certificate if requested.
• client_key_exchange: for RSA, the client generates a 48-byte pre-master secret and sends it encrypted with the server's public key; for Diffie-Hellman, the client's public DH value is sent.
• certificate_verify (if a client certificate was sent): a signature over the handshake messages proving possession of the private key.

Phase 4: Finish

• Both send change_cipher_spec to switch to the newly negotiated cipher spec.
• Each sends finished, a hash over all handshake messages and master secret, encrypted with the new keys. Successful verification confirms the handshake was not tampered with.

The master secret is computed from the pre-master secret and both random numbers, and the session keys are derived from it. After this, application data flows through the record protocol encrypted and authenticated. Session resumption uses an abbreviated handshake with the stored session ID.

Wireless networks use an open radio medium, so they face more threats than wired ones. The main threats are:

• Eavesdropping / sniffing. An attacker within radio range can capture traffic; unencrypted or weakly encrypted (WEP) traffic is readable.
• Unauthorised access. Attackers join the network through weak or default passwords, MAC spoofing, or missing authentication.
• Rogue access points. Unauthorised APs installed by employees or attackers that bypass security controls and expose the internal network.
• Evil twin / man-in-the-middle. A fake AP with the same SSID lures users, then captures credentials and traffic.
• Denial of service. Jamming the radio frequency, flooding with deauthentication or association frames, and resource exhaustion.
• Session hijacking and replay. Taking over an authenticated session or replaying captured frames.
• Cracking of keys. Attacks on WEP (IV weakness), and dictionary attacks on WPA/WPA2-PSK handshakes.
• Accidental association and ad hoc network risks. Devices joining neighbouring or malicious networks automatically; peer-to-peer ad hoc connections that bypass the AP.
• Identity theft and MAC spoofing, and malicious clients that bring malware into the network.

Countermeasures include WPA2/WPA3 with strong passphrases or 802.1X, disabling WPS, signal management, wireless IDS, regular rogue AP scans and VPN usage on public hotspots.

Use of a firewall. A firewall is a network security device placed between a trusted internal network and an untrusted external network (the Internet). It enforces the security policy by examining traffic and allowing or blocking it. Its uses are:

• Defining a single choke point where all traffic can be monitored and controlled.
• Filtering traffic by IP address, port, protocol and application, and blocking unauthorised access and attacks.
• Hiding the internal network (NAT), supporting VPN, and logging and auditing traffic.

Packet filtering vs stateful inspection firewall

IPsec provides security at the IP layer for IPv4 and IPv6, offering access control, connectionless integrity, data origin authentication, replay protection, confidentiality and limited traffic-flow confidentiality. Its architecture (RFC 4301) has the following parts.

1. Protocols

• Authentication Header (AH): provides integrity, data origin authentication and anti-replay for the packet, but no encryption.
• Encapsulating Security Payload (ESP): provides confidentiality (encryption), and optionally integrity and authentication and anti-replay.

2. Modes of operation

• Transport mode: protects the payload of the IP packet (upper-layer data) with the original IP header kept; used for end-to-end host communication.
• Tunnel mode: the entire original IP packet is protected and a new outer IP header is added; used between security gateways (VPN).

3. Security Association (SA). A one-way logical relationship that defines the security services and parameters for traffic. It is identified by a Security Parameter Index (SPI), destination IP address and security protocol (AH/ESP). Two SAs are needed for two-way communication.

4. Databases

• Security Policy Database (SPD): rules that decide for each packet whether to discard, bypass or apply IPsec.
• Security Association Database (SAD): holds the parameters of active SAs (algorithms, keys, lifetime, sequence number counter, mode).

5. Key management. Manual keying, or automatic keying with Internet Key Exchange (IKE) which negotiates SAs and keys.

6. Algorithms. Encryption such as AES and 3DES, and authentication such as HMAC-SHA.

Together these components determine how packets are classified, protected, and processed on both sending and receiving side.

Use of DNSSEC. DNS, as originally designed, has no authentication, so responses can be forged (cache poisoning, spoofing, man-in-the-middle). DNS Security Extensions (DNSSEC) add digital signatures to DNS data, giving data origin authentication, data integrity and authenticated denial of existence. It does not provide confidentiality. A resolver can verify that the answer really came from the zone's owner and was not changed. Trust is established through a chain of trust from the signed root zone, down through the top-level domains to the zone.

DNSSEC resource records

• RRSIG (Resource Record Signature). Holds the digital signature over a set of resource records (RRset), together with the signer name, algorithm, key tag and validity period (inception and expiration).
• DNSKEY. Holds the public key of the zone used to verify RRSIGs. A zone usually has a Zone Signing Key (ZSK) which signs the data and a Key Signing Key (KSK) which signs the DNSKEY set.
• DS (Delegation Signer). Placed in the parent zone; contains the hash of the child zone's KSK DNSKEY, linking the child to the parent and building the chain of trust.
• NSEC (Next Secure). Links the names in a zone in canonical order and lists the record types present, so that the non-existence of a name or type can be proved with a signed record.
• NSEC3. Like NSEC, but uses hashed owner names to prevent zone enumeration (walking the zone).
• NSEC3PARAM. Gives the parameters (hash algorithm, iterations, salt) used by NSEC3.
• CDS/CDNSKEY (optional) allow a child to signal changes of DS to its parent.

DNSSEC

DNS Security Extensions (DNSSEC) is a set of IETF extensions (RFC 4033, 4034, 4035) that add public key digital signatures to the Domain Name System. Ordinary DNS answers can be forged (cache poisoning, spoofing). DNSSEC gives resolvers data origin authentication, data integrity and authenticated denial of existence. It does not encrypt DNS data.

How it works

1. The zone owner generates a key pair: a Zone Signing Key (ZSK) and a Key Signing Key (KSK). The public keys are published as DNSKEY records.
2. Every resource record set (RRset) in the zone is signed with the ZSK private key, producing an RRSIG record. The ZSK is itself signed by the KSK.
3. A hash of the child's KSK is placed in the parent zone as a DS record, and the parent signs it. This forms a chain of trust from the root zone (whose key is the configured trust anchor) down through the TLD to the zone.
4. NSEC/NSEC3 records prove that a name or record type does not exist.
5. A validating resolver queries the record with the DO bit set, receives the data with its RRSIG, fetches the DNSKEY and DS records up the chain, and verifies each signature up to the trust anchor. If validation succeeds, the answer is accepted (AD bit set); otherwise it returns SERVFAIL.

DNS-based Authentication of Named Entities (DANE)

DANE (RFC 6698) uses DNSSEC-secured DNS to bind a server's X.509 certificate or public key to its domain name, so that clients do not need to rely only on the public CA system, where any CA can issue a certificate for any domain.

• A TLSA resource record is published for a service, named like _443._tcp.www.example.com. It contains: a certificate usage field (CA constraint, service certificate constraint, trust anchor assertion, or domain-issued certificate), a selector (full certificate or only the public key), a matching type (exact, SHA-256 or SHA-512 hash) and the certificate association data.
• When a client connects over TLS, it looks up the TLSA record (validated with DNSSEC), and compares the data with the certificate presented by the server in the handshake. If they match, the connection is accepted; otherwise it is refused.
• Benefits are protection against rogue or compromised CAs, support for self-signed certificates, and authentication of mail servers (SMTP with DANE) and other services. The security relies completely on DNSSEC validation, as an unsigned TLSA record could itself be forged.

SSH port forwarding

SSH can tunnel arbitrary TCP traffic through its encrypted connection, so that insecure applications (e.g. POP3, VNC, X11) gain confidentiality and integrity.

Local forwarding (ssh -L). A port on the SSH client machine is forwarded through the SSH server to a destination host and port.

• Command: ssh -L 8080:intranet:80 user@sshserver
• The client listens on local port 8080. When an application connects to localhost:8080, the SSH client sends the data in an encrypted channel to the SSH server, which opens a TCP connection to intranet:80 and relays the data. The direction of connection is client to server, and it is used to reach services behind a firewall.

Remote forwarding (ssh -R). A port on the SSH server is forwarded back through the client to a destination reachable from the client.

• Command: ssh -R 9000:localhost:22 user@sshserver
• The server listens on port 9000. A connection made to sshserver:9000 is sent through the encrypted tunnel to the SSH client, which then connects to localhost:22. This is used to expose an internal service to the outside through a server.

In both cases the application on one end connects to a plain TCP port, and the SSH protocol carries it in channels inside the encrypted session.

SSH connection protocol (RFC 4254)

SSH has three layers: transport layer (server authentication, key exchange, encryption, integrity), user authentication layer, and the connection protocol, which runs over the authenticated transport and multiplexes several logical channels (interactive sessions, forwarded TCP connections, X11) over one SSH connection. Each channel has a number at each end and flow-control windows.

Message exchange

1. Channel open: SSH_MSG_CHANNEL_OPEN (channel type such as session, direct-tcpip, forwarded-tcpip, x11; sender channel number; initial window size; maximum packet size). The reply is SSH_MSG_CHANNEL_OPEN_CONFIRMATION (recipient and sender channel numbers, window size) or SSH_MSG_CHANNEL_OPEN_FAILURE.
2. Channel requests: SSH_MSG_CHANNEL_REQUEST is used to request a pseudo-terminal (pty-req), start a shell, exec a command or subsystem (e.g. sftp), set environment variables, or x11-req. The peer answers SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE.
3. Global requests: SSH_MSG_GLOBAL_REQUEST such as tcpip-forward (to set up remote forwarding, with SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE reply).
4. Data transfer: SSH_MSG_CHANNEL_DATA (normal data) and SSH_MSG_CHANNEL_EXTENDED_DATA (e.g. stderr). The receiver controls flow using SSH_MSG_CHANNEL_WINDOW_ADJUST to increase the window.
5. Channel close: SSH_MSG_CHANNEL_EOF shows no more data will be sent, and SSH_MSG_CHANNEL_CLOSE is sent by each side, which closes the channel after both are exchanged.

Applications of IPsec

• Secure branch office connectivity over the Internet: a virtual private network (VPN) between offices, avoiding private leased lines.
• Secure remote access over the Internet: an employee reaches the corporate network through an ISP using an IPsec client.
• Establishing extranet and intranet connectivity with partners: authentication and confidentiality between organisations.
• Enhancing electronic commerce security: adds a layer of protection to application-level security.
• Protecting routing protocols (OSPF, BGP) and neighbour discovery, and securing any IP traffic transparently, since it is below the transport layer and needs no change to applications.

Security Association (SA) parameters

An SA is a one-way relationship between sender and receiver, identified by three parameters: Security Parameters Index (SPI), IP destination address, and security protocol identifier (AH or ESP). An SA record contains:

• Sequence number counter: a 32-bit value for generating the sequence number field in AH or ESP headers.
• Sequence counter overflow: flag showing whether overflow stops further transmission on that SA.
• Anti-replay window: to determine whether an inbound AH or ESP packet is a replay.
• AH information: authentication algorithm, keys, key lifetimes and related parameters.
• ESP information: encryption and authentication algorithms, keys, initialisation values, key lifetimes.
• Lifetime of the SA: time interval or byte count after which the SA must be replaced or terminated.
• IPsec protocol mode: tunnel, transport or wildcard.
• Path MTU: observed maximum transmission unit and ageing variables.

Security Association Database (SAD) and SPD

The SAD holds the active SAs, and the above parameters are the fields of each entry. For outbound processing, an entry in the SPD points to the SA in the SAD; for inbound processing, the SAD is indexed by SPI, destination address and protocol.

The Security Policy Database (SPD) has entries defined by selectors that decide the treatment of traffic: remote IP address, local IP address, next layer protocol, name (user or system identifier), and local and remote ports. Each entry gives an action (discard, bypass IPsec, or protect) and, for protect, points to the SA or SAs to use.

Protection of computer networks is applied in several forms that complement each other (defence in depth).

1. Physical protection. Controlled access to server rooms and cabling, locks, CCTV, power backup and environmental controls.
2. Access control and authentication. Passwords, multi-factor authentication, biometrics, role-based access control and the principle of least privilege to ensure that only authorised users reach resources.
3. Cryptographic protection. Encryption of data in transit and at rest (TLS, IPsec, SSH, VPN, WPA2), hashing and digital signatures for integrity and non-repudiation.
4. Perimeter and network protection. Firewalls, DMZ, proxy servers, network segmentation (VLAN), NAT and secure routers.
5. Detection and prevention. Intrusion detection and prevention systems, antivirus and antimalware, log monitoring and SIEM.
6. Host and application protection. Patching, hardening, endpoint security, secure coding and web application firewalls.
7. Backup and recovery. Regular backups, redundancy, disaster recovery and business continuity plans for availability.
8. Administrative protection. Security policies, user awareness training, audits, risk assessment and incident response procedures.

Together these provide preventive, detective and corrective controls to ensure confidentiality, integrity and availability.

In remote user authentication with asymmetric (public key) encryption, each party has a key pair, and public keys are obtained from a trusted authority or certificate. Notation: $PU_a$, $PR_a$ are A's public and private keys, $N$ a nonce, $T$ a timestamp.

One-way authentication (A proves itself to B)

Using a timestamp (no prior exchange required):

$A \rightarrow B:\; ID_A \,\|\, T \,\|\, E(PU_b,\, E(PR_a,\, [T \,\|\, K_s]))$

Here A signs with its private key and encrypts the result with B's public key; the timestamp prevents replay. B decrypts with $PR_b$, then verifies using $PU_a$ (obtained from a certificate or from an authentication server). A valid signature proves the identity of A and integrity, and encryption gives confidentiality of the session key $K_s$.

Alternatively with a challenge: B sends nonce $N_b$; A returns $E(PR_a, N_b)$ and B verifies with $PU_a$.

Mutual authentication (both A and B prove themselves)

1. $A \rightarrow B:\; E(PU_b,\, [N_a \,\|\, ID_A])$. A sends its identity and a nonce $N_a$, encrypted to B.
2. $B \rightarrow A:\; E(PU_a,\, [N_a \,\|\, N_b])$. B decrypts it (showing it holds $PR_b$), and returns $N_a$ together with its own nonce $N_b$. A decrypts and checks that $N_a$ matches, which authenticates B.
3. $A \rightarrow B:\; E(PU_b,\, N_b)$. A returns $N_b$, which authenticates A to B.

Optionally, a session key $K_s$ can be sent as $E(PU_b, E(PR_a, K_s))$ for later symmetric communication. When public keys are not known in advance, a trusted authentication server or certificate authority provides them as signed certificates. Nonces and timestamps protect against replay attacks.

Change Cipher Spec protocol

This is the simplest TLS protocol, consisting of a single message of one byte with the value 1. Its purpose is to cause the pending cipher state to be copied into the current state, which updates the cipher suite (encryption algorithm, MAC algorithm and keys) to be used on this connection. Both client and server send it after the key exchange, just before the finished message of the handshake; all following records are protected by the newly negotiated parameters. It is sent over the TLS record protocol.

Alert protocol

The alert protocol conveys TLS-related alerts to the peer. Each message has two bytes: the first is the level (warning = 1 or fatal = 2) and the second is a code that specifies the alert. Like other TLS data, alerts are compressed and encrypted according to the current state.

• Fatal alerts immediately terminate the connection (and other connections of the session are not resumed). Examples: unexpected_message, bad_record_mac, decompression_failure, handshake_failure, illegal_parameter.
• Warning alerts are for less serious conditions. Examples: close_notify (sender will not send more messages on this connection, used to prevent truncation attacks), no_certificate, bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown.

In IEEE 802.11i (WPA2/RSN) the operation has five phases: discovery, authentication, key management, protected data transfer, and connection termination. The four-way handshake and group key handshake belong to the key management phase. Both start from the Pairwise Master Key (PMK), which is derived from the authentication phase (802.1X/EAP, or the pre-shared key). The keys are generated by the supplicant (station STA) and authenticator (access point AP).

Four-way handshake (establishes the Pairwise Transient Key, PTK)

1. Message 1, AP to STA: AP sends a nonce $ANonce$.
2. Message 2, STA to AP: STA generates its nonce $SNonce$ and computes the PTK from PMK, both nonces and both MAC addresses: $PTK = PRF(PMK,\, ANonce \,\|\, SNonce \,\|\, MAC_{AP} \,\|\, MAC_{STA})$ It sends $SNonce$ with a Message Integrity Code (MIC) computed using the key confirmation key (KCK) part of the PTK.
3. Message 3, AP to STA: AP computes the same PTK, verifies the MIC, and sends a message with MIC, the group temporal key (GTK) encrypted, and an instruction to install the keys.
4. Message 4, STA to AP: STA acknowledges (with MIC) and installs the PTK, which confirms to the AP that the keys are installed.

The PTK is split into KCK (for MICs), KEK (key encryption key, for protecting GTK) and TK (temporal key used for data encryption and integrity).

Group key handshake (distributes the Group Temporal Key, GTK, for multicast/broadcast)

1. AP to STA: a message containing the new GTK encrypted with the KEK and protected with a MIC (using KCK).
2. STA to AP: an acknowledgment with MIC after it installs the GTK.

The AP does this for every associated station whenever the group key must be changed (for example when a device leaves the network). The GTK is used to protect group-addressed traffic.

Both TKIP and CCMP are data confidentiality and integrity protocols of IEEE 802.11i. TKIP was designed as a software patch to WEP for old hardware, and CCMP is the stronger, hardware-based design of WPA2.

Sender Policy Framework (SPF) is an e-mail authentication method (RFC 7208) that prevents sender address forgery (spoofing) of the envelope sender (MAIL FROM) and HELO domain. A domain owner publishes a list of the mail servers that are authorised to send mail for the domain, as a DNS TXT record, and receivers check it.

Sender (domain owner) side

• The domain administrator publishes an SPF record in the DNS zone, for example:

  example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 mx include:_spf.google.com -all"

• The record lists authorised sources using mechanisms such as ip4, ip6, a, mx, include, and ends with an all qualifier: -all (fail: reject), ~all (softfail: accept but mark) or ?all (neutral).

• Mail is sent only from the listed servers, and the list must be updated whenever the sending infrastructure changes.

Receiver side

1. The receiving mail server gets an SMTP connection from client IP address $IP$ with MAIL FROM:<user@example.com>.
2. It extracts the domain example.com and queries DNS for its SPF (TXT) record.
3. It evaluates the mechanisms in order to see whether $IP$ matches an authorised source.
4. The result is pass, fail, softfail, neutral, none, temperror or permerror.
5. Based on the result and local policy (often combined with DKIM and DMARC), the server accepts, rejects or marks the message as spam, and records the result in the Received-SPF or Authentication-Results header.

Limitations are that SPF breaks on message forwarding and does not check the visible From: header, so it is normally used together with DKIM and DMARC.

An Intrusion Detection System (IDS) monitors network traffic or host activity for malicious actions or policy violations and raises alerts (an Intrusion Prevention System, IPS, in addition blocks them). It adds a detective layer of security behind the firewall.

Types by placement

• Network-based IDS (NIDS): sensors on network segments (using a span port or tap) analyse packets, e.g. port scans, DoS floods, exploit signatures.
• Host-based IDS (HIDS): agents on servers check system logs, file integrity, system calls and processes, detecting insider misuse and compromised hosts.

Detection methods

• Signature-based (misuse) detection: matches traffic against a database of known attack patterns. Accurate for known attacks but cannot detect new ones.
• Anomaly-based detection: builds a profile of normal behaviour and flags deviations. It can find novel attacks, but may give false positives.

How it is used to secure the network

1. Place sensors at the network perimeter, in the DMZ and at critical internal segments, and install HIDS on critical servers.
2. Tune rules and signatures (e.g. Snort, Suricata) and update them regularly.
3. Collect alerts and logs in a central console/SIEM for correlation.
4. Respond: notify administrators, log the event, reconfigure the firewall to block the source, or reset the connection (IPS).
5. Use the information for forensics, auditing and improving the policy.

An IDS does not replace firewalls, but detects attacks that bypass them, helps in early warning, and gives evidence for investigation.

Cloud computing (IaaS, PaaS, SaaS; public, private, hybrid) gives scalability but moves data and control to a provider and shares resources with other tenants.

Cloud security risks (threats)

• Abuse and nefarious use of cloud computing, e.g. hosting malware, spam or botnets using cheap resources.
• Insecure interfaces and APIs, weak authentication or access control in management APIs.
• Malicious insiders at the provider or customer.
• Shared technology issues, such as weak isolation between virtual machines (hypervisor attacks, side channels).
• Data loss or leakage, data breach, deletion, loss of encryption keys, and data remanence.
• Account or service hijacking through phishing, stolen credentials.
• Unknown risk profile and lack of transparency, loss of control over patching and logs.
• Compliance and legal risks, data location/jurisdiction and vendor lock-in; denial of service and availability issues.

Countermeasures

• Strong identity and access management, multi-factor authentication and least privilege.
• Encrypt data at rest and in transit, with customer-managed keys where possible.
• Secure APIs with authentication, authorisation, input validation and monitoring.
• Network segmentation, virtual firewalls, hypervisor hardening and VM isolation.
• Logging, monitoring, auditing and intrusion detection, with regular vulnerability scanning and patching.
• Backup, replication and disaster recovery plans; clear service level agreements (SLAs).
• Vendor due diligence, compliance certification (ISO 27001, SOC 2), and background checks and separation of duties.
• Security awareness and training for staff, and a shared responsibility model with defined duties for provider and customer.

IoT environments contain constrained devices, gateways, networks and cloud services, and are secured by applying controls at every layer and across the device life cycle.

1. Device security. Unique device identity and credentials (no default passwords), secure boot and signed firmware, hardware root of trust (TPM or secure element), tamper resistance, disabling unused ports and services, and encryption of stored data.
2. Secure communication. Encrypt and authenticate all traffic using TLS/DTLS, lightweight protocols suitable for constrained devices, link-layer security (802.15.4, BLE pairing, WPA2/3) and VPN where possible.
3. Authentication and authorisation. Mutual authentication between devices, gateway and cloud using certificates or keys; role-based and least privilege access; secure API tokens (OAuth).
4. Gateway and network security. Gateway acting as a security enforcement point with firewall, filtering and intrusion detection; network segmentation to isolate IoT devices from critical systems.
5. Update and patch management. Secure over-the-air firmware updates with signature verification and rollback protection.
6. Cloud and data security. Protect back-end platforms, access control, encryption of data, privacy controls and data minimisation.
7. Monitoring and incident response. Logging, anomaly detection, device health monitoring, and ability to revoke or quarantine compromised devices.
8. Life-cycle management. Secure provisioning, key management, and secure decommissioning and data wiping.

Applying these defends against attacks such as botnets (Mirai), eavesdropping, spoofing, firmware tampering and denial of service.