Dean's Office Official Model Question Paper

Answer:

• Symmetric Cryptography (Secret-Key): Uses a single shared secret key for both encryption and decryption. It is computationally fast (high throughput, low CPU overhead) but suffers from complex key distribution ($O(n^2)$ keys required for $n$ users) (e.g., AES-256, ChaCha20).
• Asymmetric Cryptography (Public-Key): Uses mathematically linked key pairs (public key for encryption/verification, private key for decryption/signing). Solves key exchange ($2n$ keys for $n$ users) but is computationally much slower (100–1000x slower due to large modular arithmetic) (e.g., RSA-3072, ECC/Ed25519).

Answer: Certificate Authority (CA): A trusted third-party entity in a PKI that digitally signs and issues X.509 digital identity certificates.

• Role: It binds an entity’s identity (domain name, organization, public key) to prevent Man-in-the-Middle (MITM) impersonation attacks. Relying parties verify the CA’s digital signature using trusted root certificates embedded in operating systems and browsers.

Answer:

• Stateful Packet Inspection (SPI): Tracks active TCP connections, session states, and sequence numbers in a dynamic state table. Incoming packets are permitted only if they match an established, legitimate outbound connection session (or explicit allow rule).
• Stateless Packet Filtering: Evaluates each packet in isolation against static rules based solely on header fields (Source IP, Destination IP, Port, Protocol) without awareness of connection context or TCP handshake state.

Answer: Electronic Record (ETA 2063, Sec 2(n)): Data, record, or data generated, sent, received, or stored in electronic, digital, magnetic, optical, or photographic form, including microfilm, computer-generated microfiche, emails, electronic text messages, and databases. The Act grants electronic records legal recognition, validity, and admissibility in court on par with physical paper documents.

Answer:

• Denial-of-Service (DoS): An attack launched from a single computer or IP address attempting to exhaust server memory, bandwidth, or CPU cycles to render services unavailable to legitimate users. Easily mitigated via simple firewall IP blacklisting.
• Distributed Denial-of-Service (DDoS): An attack orchestrated across thousands of compromised hosts (botnet/zombies) distributed globally, overwhelming target infrastructure via volumetric floods (SYN flood, UDP reflection, HTTP GET storms). Requires distributed scrubbing centers and CDN mitigation.

RSA Public-Key Cryptosystem: Mathematical Foundations and Numerical Demonstration

1. Mathematical Foundations

The RSA algorithm (Rivest, Shamir, Adleman) relies on the computational intractability of factoring the product of two large prime numbers (the Integer Factorization Problem) and Euler’s Totient Theorem:

1. Select two distinct large prime numbers $p$ and $q$.
2. Compute the RSA modulus:
   $$n = p \times q$$
3. Compute Euler’s totient function:
   $$\phi(n) = (p - 1)(q - 1)$$
4. Select a public exponent $e$ such that $1 < e < \phi(n)$ and $\gcd(e, \phi(n)) = 1$.
5. Compute the private exponent $d$ as the modular multiplicative inverse of $e$ modulo $\phi(n)$:
   $$d \equiv e^{-1} \pmod{\phi(n)} \iff (e \times d) \equiv 1 \pmod{\phi(n)}$$
6. Public Key: $(e, n)$ Private Key: $(d, n)$

2. Concrete Numerical Demonstration

Let us select small primes: $p = 61$ and $q = 53$:

1. Modulus:
   $$n = 61 \times 53 = 3233$$
2. Totient:
   $$\phi(n) = (61 - 1) \times (53 - 1) = 60 \times 52 = 3120$$
3. Choose public exponent $e$: Let $e = 17$. Verify $\gcd(17, 3120) = 1$.
4. Compute private key $d$ using the Extended Euclidean Algorithm:
   $$17 \times d \equiv 1 \pmod{3120} \implies d = 2753$$
   (Verification: $17 \times 2753 = 46801 = 15 \times 3120 + 1$).

Encryption:

Let plaintext message $M = 65$ (ASCII ‘A’):

$$C = M^e \pmod{n} = 65^{17} \pmod{3233} = 2790$$

Decryption:

Recover plaintext $M$ using private key $d$:

$$M = C^d \pmod{n} = 2790^{2753} \pmod{3233} = 65$$

3. Common Attack Vectors and Modern Mitigations

Advanced Encryption Standard (AES): Architecture, Round Operations, and Modes

1. Architectural Overview of AES (Rijndael Cipher)

AES is a symmetric-key block cipher operating on 128-bit blocks organized as a $4 \times 4$ column-major matrix of bytes called the State Array. Key sizes determine the number of transformation rounds $N_r$:

• AES-128: 10 rounds (128-bit key)
• AES-192: 12 rounds (192-bit key)
• AES-256: 14 rounds (256-bit key)

Plaintext Block (16 Bytes) -> AddRoundKey (Round 0)
     |
     v
[Round 1 to Nr - 1]:
  1. SubBytes    (Non-linear S-Box Byte Substitution)
  2. ShiftRows   (Cyclic left byte shift across rows)
  3. MixColumns  (Galois Field GF(2^8) Matrix Multiplication)
  4. AddRoundKey (XOR with expanded round key)
     |
     v
[Final Round Nr]:
  1. SubBytes -> 2. ShiftRows -> 3. AddRoundKey (MixColumns Omitted)
     |
     v
Ciphertext Block (16 Bytes)

2. The Four Fundamental Round Transformations

1. SubBytes: An invertible non-linear substitution step where each byte in the State Array is replaced with another byte according to an 8-bit substitution box (S-Box), derived from the multiplicative inverse over $\text{GF}(2^8)$ combined with an affine transformation. Provides confusion.
2. ShiftRows: A linear diffusion step where rows of the state array are cyclically shifted to the left by row offsets:
   • Row 0: 0 bytes shifted
   • Row 1: 1 byte shifted left
   • Row 2: 2 bytes shifted left
   • Row 3: 3 bytes shifted left
3. MixColumns: A matrix multiplication step where each 4-byte column is transformed by multiplying with a fixed invertible polynomial $c(x) = \{03\}x^3 + \{01\}x^2 + \{01\}x + \{02\}$ modulo $x^4 + 1$ in $\text{GF}(2^8)$. Provides inter-byte diffusion.
4. AddRoundKey: The 128-bit State Array is bitwise XORed with the corresponding 128-bit Round Key generated by the Rijndael Key Schedule algorithm.

3. Comparison of AES Block Cipher Modes

Digital Signatures, PKI Architecture, and Implementation

1. Digital Signature Mechanics

A digital signature provides three fundamental cryptographic assurances:

1. Integrity: Message has not been altered in transit ($H(M) == H(M')$).
2. Authenticity: Confirms the signer’s identity using public-key verification.
3. Non-Repudiation: The signer cannot claim they did not generate the message because only their private key could produce the signature.

Signing Process (Sender):
Message M -> SHA-256 Hash -> Hash Digest -> Encrypt with Private Key (Sender) -> Digital Signature S

Verification Process (Receiver):
Received M -> SHA-256 Hash -> Local Digest H1
Received S -> Decrypt with Public Key (Sender) -> Recovered Digest H2
Decision: If (H1 == H2) -> SIGNATURE VALID; Else -> TAMPERED / REJECT

2. X.509 Digital Certificate Standard Structure

An X.509 v3 certificate consists of:

• Version: Version number (v3).
• Serial Number: Unique integer assigned by the issuing CA.
• Signature Algorithm ID: (e.g., SHA256withRSAEncryption).
• Issuer: Distinguished Name (DN) of the Certificate Authority.
• Validity Period: Not Before and Not After timestamps.
• Subject: Distinguished Name of the certificate owner (e.g., CN=api.himalayanpay.com.np).
• Subject Public Key Info: Public key algorithm and public key bitstring.
• Extensions: Key Usage, Subject Alternative Name (SAN), CRL Distribution Points.
• CA Digital Signature: Cryptographic signature over all preceding fields by the CA.

3. Working Python Implementation: Digital Signing and Verification

import hashlib
import hmac

class DigitalSignatureSimulator:
    # Demonstrates digital signature generation and verification principles
    # using SHA-256 message hashing and RSA simulated private/public key primitives.
    @staticmethod
    def hash_message(message: str) -> bytes:
        return hashlib.sha256(message.encode('utf-8')).digest()

    @staticmethod
    def sign(message: str, private_secret_key: bytes) -> bytes:
        digest = DigitalSignatureSimulator.hash_message(message)
        # Using HMAC-SHA256 as deterministic signature generator for demonstration
        signature = hmac.new(private_secret_key, digest, hashlib.sha256).digest()
        return signature

    @staticmethod
    def verify(message: str, signature: bytes, public_verification_key: bytes) -> bool:
        expected_digest = DigitalSignatureSimulator.hash_message(message)
        expected_sig = hmac.new(public_verification_key, expected_digest, hashlib.sha256).digest()
        return hmac.compare_digest(signature, expected_sig)

# Verification demonstration
if __name__ == "__main__":
    secret_key = b"private_key_nepal_fintech_gateway_2080"
    payload = '{"transaction_id": "TXN9982", "amount": 25000, "currency": "NPR"}'

    # 1. Sign
    sig = DigitalSignatureSimulator.sign(payload, secret_key)
    print("Generated Signature (hex):", sig.hex()[:32], "...")

    # 2. Verify legitimate payload
    is_valid = DigitalSignatureSimulator.verify(payload, sig, secret_key)
    print("Legitimate payload verified:", is_valid)  # True

    # 3. Verify tampered payload
    tampered_payload = '{"transaction_id": "TXN9982", "amount": 99999, "currency": "NPR"}'
    is_tampered_valid = DigitalSignatureSimulator.verify(tampered_payload, sig, secret_key)
    print("Tampered payload rejected:", not is_tampered_valid)  # True

Nepal Electronic Transactions Act, 2063 (ETA 2063): Legal Framework and Cyber Offenses

1. Legislative Objectives and Regulatory Architecture

Enacted in 2063 BS (2006 AD), the Electronic Transactions Act, 2063 is Nepal’s principal statutory legislation governing cyber operations, e-commerce, digital signatures, and computer crimes.

• Core Objectives:
  • Grant legal validity to electronic records, contracts, and digital signatures.
  • Create a secure digital transaction environment for government (e-Governance) and private commerce.
  • Prevent and criminalize illegal activities involving computer systems, networks, and data.
• Institutional Machinery:
  • Controller of Certifying Authorities: Regulatory body under the Ministry of Communication and Information Technology overseeing Certifying Authorities (CAs) and verifying digital signature standards.
  • Certifying Authority (CA): Entities licensed by the Controller to issue digital identity certificates (e.g., Nepal Certifying Company).

2. Key Cyber Offenses and Penalties Under Chapter 9

3. Judicial Adjudication: The Cyber Appellate Tribunal

• Under Chapter 10 of ETA 2063, the Government of Nepal establishes the Cyber Appellate Tribunal.
• Composition: Composed of a Chairperson (eligible for High Court Judge) and two members (one legal expert and one information technology expert).
• Jurisdiction: Hears appeals against decisions and orders made by the Controller or the Adjudicating Officer regarding cyber disputes, digital certificate revocations, and cybercrime damages.

Comprehensive System & Legal Solution: Himalayan FinTech Gateway

a) Root-Cause Vulnerability Analysis and Zero-Trust Architecture

1. Root-Cause Analysis of Exploitation Vectors

1. Lack of Mutual TLS (mTLS) & Certificate Pinning: The merchant API endpoint allowed connections using legacy TLS 1.1 without certificate pinning, allowing attackers on compromised Wi-Fi or ISP routers to inject bogus certificates and decrypt payloads.
2. Absence of Payload Cryptographic Signatures: Transaction callbacks relied solely on static API secret keys in headers rather than signing payload bodies (amount, merchant ID, timestamp) with asymmetric private keys.
3. Plaintext Sensitive Logging (Data At Rest): Personally Identifiable Information (PII) and banking tokens were written unencrypted to plaintext log files violating PCI-DSS and NRB Data Governance mandates.

2. Zero-Trust Defense-in-Depth Architecture

[Merchant Systems]
        |
        v (1. Mutual TLS 1.3 with Certificate Pinning)
[Cloudflare / AWS CloudFront DDoS & WAF Layer] -> Filters SQLi, XSS, and Rate Limit
        |
        v
[Next-Generation Firewall (NGFW) & DMZ Perimeter]
        |
        v
[API Gateway (mTLS Termination, JWT Auth, Replay Nonce Check)]
        |
        v (2. Micro-segmentation / Service Mesh Istio with mTLS)
+-------------------------------------------------------------+
| Private Application Subnet (Strict Network Policies)         |
|  [Payment Aggregator] ---> [Cryptographic Verification Pod]  |
|           |                                                 |
|           v (3. Encrypted Transactions via KMS / HSM)       |
|  [Core Database Cluster (AES-256 Transparent Data Encryption)]|
+-------------------------------------------------------------+

• Principle of Least Privilege: Services cannot talk directly across zones without explicit mutual authentication.
• WAF Layer: Inspects HTTP payloads for anomalous JSON patterns, blocking parameter tampering before application ingestion.

---

b) End-to-End Cryptographic Implementation in Python

Below is the complete, self-contained Python module implementing AES-256-GCM authenticated encryption and HMAC-SHA256 digital payload signing preventing callback tampering:

import os
import base64
import hashlib
import hmac
from datetime import datetime, timezone

class PaymentCryptoEngine:
    # Cryptographic engine providing AES-256-GCM authenticated encryption (AEAD)
    # and HMAC-SHA256 payload signing for financial switches.
    @staticmethod
    def sign_payload(payload_dict: dict, secret_signing_key: bytes) -> str:
        # Canonicalize JSON to guarantee identical byte serialization
        canonical_bytes = json.dumps(payload_dict, sort_keys=True, separators=(',', ':')).encode('utf-8')
        signature = hmac.new(secret_signing_key, canonical_bytes, hashlib.sha256).hexdigest()
        return signature

    @staticmethod
    def verify_payload_signature(payload_dict: dict, signature: str, secret_signing_key: bytes) -> bool:
        expected_sig = PaymentCryptoEngine.sign_payload(payload_dict, secret_signing_key)
        return hmac.compare_digest(expected_sig, signature)

    @staticmethod
    def encrypt_payload_mock_aes_gcm(plaintext_data: str, key_32bytes: bytes) -> dict:
        # Simulates AES-256-GCM encryption with IV, Ciphertext, and Auth Tag.
        nonce = os.urandom(12)  # 96-bit standard GCM nonce
        # Simulated stream cipher XOR for standard library execution
        keystream = hashlib.sha256(key_32bytes + nonce).digest()
        plain_bytes = plaintext_data.encode('utf-8')
        cipher_bytes = bytes([b ^ keystream[i % len(keystream)] for i, b in enumerate(plain_bytes)])

        # Compute GCM authentication tag
        auth_tag = hmac.new(key_32bytes, nonce + cipher_bytes, hashlib.sha256).digest()[:16]

        return {
            "nonce": base64.b64encode(nonce).decode('utf-8'),
            "ciphertext": base64.b64encode(cipher_bytes).decode('utf-8'),
            "tag": base64.b64encode(auth_tag).decode('utf-8')
        }

    @staticmethod
    def decrypt_payload_mock_aes_gcm(enc_package: dict, key_32bytes: bytes) -> str:
        nonce = base64.b64decode(enc_package["nonce"])
        cipher_bytes = base64.b64decode(enc_package["ciphertext"])
        tag = base64.b64decode(enc_package["tag"])

        # Verify tag before decryption (Encrypt-then-MAC authenticity)
        expected_tag = hmac.new(key_32bytes, nonce + cipher_bytes, hashlib.sha256).digest()[:16]
        if not hmac.compare_digest(expected_tag, tag):
            raise ValueError("MAC Authentication Failed! Payload has been tampered with.")

        keystream = hashlib.sha256(key_32bytes + nonce).digest()
        plain_bytes = bytes([b ^ keystream[i % len(keystream)] for i, b in enumerate(cipher_bytes)])
        return plain_bytes.decode('utf-8')

# Self-contained operational execution
if __name__ == "__main__":
    aes_key = os.urandom(32)  # 256-bit symmetric key
    signing_key = os.urandom(32)

    transaction = {
        "txn_id": "HFG-2080-8848",
        "merchant_id": "MERCHANT_DARAZ_01",
        "amount_npr": 50000.0,
        "customer_account": "9841234567",
        "timestamp_utc": datetime.now(timezone.utc).isoformat()
    }

    # 1. Sign transaction payload
    sig = PaymentCryptoEngine.sign_payload(transaction, signing_key)
    print("Digital Payload Signature:", sig)

    # 2. Tampering test: Attacker changes amount from 50000.0 to 50.0
    tampered_transaction = dict(transaction)
    tampered_transaction["amount_npr"] = 50.0
    is_valid = PaymentCryptoEngine.verify_payload_signature(tampered_transaction, sig, signing_key)
    print("Tampered transaction approved:", is_valid)  # False: Tampering blocked!

    # 3. Encrypt transaction for storage / wire
    encrypted_pkg = PaymentCryptoEngine.encrypt_payload_mock_aes_gcm(json.dumps(transaction), aes_key)
    print("Encrypted Package Tag:", encrypted_pkg["tag"])

    # 4. Decrypt transaction
    decrypted_str = PaymentCryptoEngine.decrypt_payload_mock_aes_gcm(encrypted_pkg, aes_key)
    recovered_data = json.loads(decrypted_str)
    print("Decrypted Amount:", recovered_data["amount_npr"])

---

c) Statutory Compliance and Legal Analysis Under ETA 2063

1. Forensic Evidence Preservation and Reporting Duties

• Incident Reporting Mandate: Under NRB Cyber Security Directives and ETA guidelines, HFG must formally report the cyber security incident to the Payment Systems Department (NRB) and the Nepal Police Cyber Bureau within 24 hours.
• Forensic Evidence Preservation (Chain of Custody):
  • Bit-stream forensic disk images (using tools like dd or EnCase) must be taken of compromised servers with cryptographic SHA-256 hashes recorded immediately.
  • Volatile memory (RAM) dumps must be captured to preserve in-memory malware artifacts.
  • Under Section 56 of ETA 2063, computer records and logs presented in court are legally admissible provided evidence authenticity and unbroken custody can be demonstrated.

2. Legal Liabilities and Statutory Penalties for Perpetrators

Perpetrators face multiple criminal counts under Chapter 9 of the Nepal Electronic Transactions Act, 2063:

1. Section 45 (Hacking / Unauthorized Access): For gaining illegal access to the payment switch and intercepting API data. Penalty: Up to 3 years imprisonment or fine up to NPR 200,000, or both.
2. Section 46 (Damage to Computer Systems & Tampering): For altering financial callback values. Penalty: Up to 3 years imprisonment or fine up to NPR 200,000, or both.
3. Section 52 (Computer Fraud): For attempting to unlawfully divert funds and extort Bitcoin. Perpetrators must fully compensate HFG and merchants for all financial damages, plus fines up to NPR 100,000 or up to 2 years imprisonment.
4. Corporate Accountability of HFG: If the regulatory investigation proves gross negligence by HFG executives in storing sensitive citizen data in plaintext, NRB possesses statutory authority to suspend HFG’s PSO operating license and levy administrative fines under the National Payment System Act, 2075.