BSc CSIT (TU) Science BIT Information Security (BIT303) – 5th Semester (Model) Question Paper 2079 Nepal

RSA Encryption and Decryption

RSA is a public-key (asymmetric) cryptosystem based on the difficulty of factoring large integers.

Key generation:

1. Choose two large primes $p$ and $q$.
2. Compute $n = p \times q$ and $\phi(n) = (p-1)(q-1)$.
3. Choose a public exponent $e$ such that $1 < e < \phi(n)$ and $\gcd(e, \phi(n)) = 1$.
4. Compute the private exponent $d$ such that $d \cdot e \equiv 1 \pmod{\phi(n)}$.

• Public key: $(e, n)$
• Private key: $(d, n)$

Encryption: For a message block $M$ ($0 \le M < n$):

$$C = M^{e} \bmod n$$

Decryption:

$$M = C^{d} \bmod n$$

(a) Finding the private key $d$

Given $n = 55$ and $e = 3$. Factor $n$:

$$n = 55 = 5 \times 11 \quad \Rightarrow \quad p = 5,\ q = 11$$ $$\phi(n) = (5-1)(11-1) = 4 \times 10 = 40$$

We need $d$ such that $3d \equiv 1 \pmod{40}$.

Using the Extended Euclidean Algorithm: $3 \times 27 = 81 = 2\times 40 + 1 \equiv 1 \pmod{40}$.

$$\boxed{d = 27}$$

Verification: $3 \times 27 = 81 = 81 - 80 = 1 \pmod{40}$. ✓

(b) Cipher text $C$ for $M =$ "hi"

Map letters to numbers (using $a=0, b=1, \dots$, i.e. position in alphabet minus 1; here we encrypt each character separately so that $M < n = 55$):

• $h \rightarrow 7$
• $i \rightarrow 8$

Encrypt 'h' ($M = 7$):

$$C = 7^{3} \bmod 55 = 343 \bmod 55$$ $$343 = 6 \times 55 + 13 \Rightarrow C_h = 13$$

Encrypt 'i' ($M = 8$):

$$C = 8^{3} \bmod 55 = 512 \bmod 55$$ $$512 = 9 \times 55 + 17 \Rightarrow C_i = 17$$

Cipher text: $C = (13,\ 17)$.

(If a different letter-to-number mapping such as $a=1,\dots,i=9$ is used, then $h=8, i=9$ giving $C = (8^3\bmod55,\ 9^3\bmod55) = (17, 14)$. The method is identical; state your mapping.)

Access Control Matrix

The access control matrix has one row per subject (user) and one column per object (file). Each cell lists the rights the user has on that file. Abbreviations: r = read, w = write, a = append.

(U2 can read all files, so r on F1–F4, plus w on F2.)

Access Control List (ACL)

An ACL is the matrix stored by column — for each file, the list of (user → rights) entries:

• F1: { U2: r }
• F2: { U1: r,w ; U2: r,w }
• F3: { U1: r,w ; U2: r ; U3: r }
• F4: { U2: r ; U3: a }

Capability List

A capability list is the matrix stored by row — for each user, the list of (file → rights) capabilities they hold:

• U1: { F2: r,w ; F3: r,w }
• U2: { F1: r ; F2: r,w ; F3: r ; F4: r }
• U3: { F3: r ; F4: a }

Difference: An ACL is associated with each object (good for answering "who can access this file?"), whereas a capability list is associated with each subject (good for answering "what can this user access?").

Properties of a (Cryptographic) Hash Function

1. Fixed output size – any input of arbitrary length maps to a fixed-length digest (160 bits for SHA-1).
2. Preimage resistance (one-way) – given a hash $h$, it is computationally infeasible to find $M$ such that $H(M) = h$.
3. Second preimage resistance – given $M_1$, it is infeasible to find $M_2 \ne M_1$ with $H(M_1) = H(M_2)$.
4. Collision resistance – it is infeasible to find any two distinct messages $M_1, M_2$ with $H(M_1) = H(M_2)$.
5. Deterministic & efficient – the same input always gives the same output, and it is fast to compute.
6. Avalanche effect – a small change in input produces a drastically different output.

Padding the Message in SHA-1

SHA-1 processes the message in 512-bit blocks, so the message must be padded to a multiple of 512 bits:

1. Append a single '1' bit to the end of the message.
2. Append '0' bits until the length is congruent to $448 \bmod 512$ (i.e. 64 bits short of a multiple of 512).
3. Append the original message length as a 64-bit big-endian integer.

The result is a sequence of $N$ blocks of 512 bits each: $M^{(1)}, M^{(2)}, \dots, M^{(N)}$.

Message Schedule $W_0 \dots W_{79}$

Each 512-bit block is split into sixteen 32-bit words $W_0 \dots W_{15}$. The schedule is then expanded (elongated) to 80 words:

$$W_t = \text{ROTL}^{1}\big(W_{t-3} \oplus W_{t-8} \oplus W_{t-14} \oplus W_{t-16}\big), \quad 16 \le t \le 79$$

where $\text{ROTL}^1$ is a left circular rotation by 1 bit.

Computing the Hash (the 80 rounds)

Five working variables are initialised from the current hash value $H_0 \dots H_4$:

$$A = H_0,\ B = H_1,\ C = H_2,\ D = H_3,\ E = H_4$$

For each round $t = 0$ to $79$:

$$T = \text{ROTL}^{5}(A) + f_t(B,C,D) + E + W_t + K_t$$ $$E = D,\quad D = C,\quad C = \text{ROTL}^{30}(B),\quad B = A,\quad A = T$$

where $f_t$ and $K_t$ are the round function and constant for the group of 20 rounds containing $t$.

After the 80 rounds, the block's output is added to the chaining value:

$$H_0 \mathrel{+}= A,\ H_1 \mathrel{+}= B,\ \dots,\ H_4 \mathrel{+}= E$$

After all $N$ blocks, the 160-bit digest is $H_0 \Vert H_1 \Vert H_2 \Vert H_3 \Vert H_4$.

Expressions after the last pass ($t = 79$)

Using the register-shift relations above, after the final round the values are:

$$A_{79} = \text{ROTL}^{5}(A_{78}) + f_{79}(B_{78}, C_{78}, D_{78}) + E_{78} + W_{79} + K_{79}$$

where for rounds $60 \le t \le 79$, $f_t(B,C,D) = B \oplus C \oplus D$ and $K_{79} = \text{0xCA62C1D6}$, so:

$$A_{79} = \text{ROTL}^{5}(A_{78}) + (B_{78} \oplus C_{78} \oplus D_{78}) + E_{78} + W_{79} + \text{0xCA62C1D6}$$ $$B_{79} = A_{78}$$ $$C_{79} = \text{ROTL}^{30}(B_{78})$$

(All additions are modulo $2^{32}$.)

Attack Tree

An attack tree is a hierarchical, graphical model used to represent the different ways a system can be attacked. The root node is the attacker's ultimate goal, and the child nodes represent the sub-goals or steps needed to achieve it. Nodes are combined using:

• AND nodes – all child sub-goals must be achieved.
• OR nodes – any one child sub-goal is sufficient.

Leaf nodes are concrete attack actions. Attack trees help in threat modeling, identifying vulnerabilities and prioritising defences.

Attack Tree: Defeat Internet Banking Authentication

Goal (root): Gain unauthorised access to a user's internet banking account
   |  (OR)
   +-- 1. Steal login credentials
   |       | (OR)
   |       +-- 1.1 Phishing email / fake bank website
   |       +-- 1.2 Keylogger / malware on user's device
   |       +-- 1.3 Shoulder surfing
   |       +-- 1.4 Guess / brute-force weak password
   |
   +-- 2. Bypass two-factor authentication (AND with step 1)
   |       | (OR)
   |       +-- 2.1 SIM-swap to intercept OTP
   |       +-- 2.2 Malware intercepting SMS/OTP
   |       +-- 2.3 Social-engineer the OTP from the victim
   |
   +-- 3. Hijack an active session
   |       | (OR)
   |       +-- 3.1 Session-cookie theft (XSS)
   |       +-- 3.2 Man-in-the-middle on insecure network
   |
   +-- 4. Compromise the bank server / database directly

Here the root is reached via OR branches; branch 2 typically requires step 1 first, so credential theft AND OTP bypass together defeat two-factor authentication.

Extended Euclidean Algorithm

The Extended Euclidean Algorithm computes $\gcd(a, b)$ and also finds integers $x, y$ (Bézout coefficients) such that:

$$a \cdot x + b \cdot y = \gcd(a, b)$$

Algorithm (pseudocode):

ExtendedEuclid(a, b):
    if b == 0:
        return (a, 1, 0)          // gcd = a, x = 1, y = 0
    (g, x1, y1) = ExtendedEuclid(b, a mod b)
    x = y1
    y = x1 - (a div b) * y1
    return (g, x, y)

Illustration for $a = 84$, $b = 320$

Forward (Euclid) steps:

So $\gcd(84, 320) = 4$.

Back-substitution to find $x, y$ with $84x + 320y = 4$:

$$4 = 68 - 4 \times 16$$ $$= 68 - 4(84 - 1\times 68) = 5\times 68 - 4\times 84$$ $$= 5(320 - 3\times 84) - 4\times 84 = 5\times 320 - 19\times 84$$

Therefore:

$$84 \times (-19) + 320 \times 5 = 4$$

Result: $\gcd = 4$, with $x = -19$, $y = 5$.

Digital Signature

A digital signature is a cryptographic mechanism that binds a message to the identity of its sender using the sender's private key. It provides:

• Authentication – proves who sent the message.
• Integrity – proves the message was not altered.
• Non-repudiation – the sender cannot later deny having signed it.

It is the digital equivalent of a handwritten signature but is far harder to forge.

Using a Digital Signature for Message Authentication

Signing (by sender, using private key):

1. Compute a hash (digest) of the message: $h = H(M)$.
2. Encrypt the hash with the sender's private key to create the signature:

$$S = E_{\text{priv}}(h)$$

3. Send $(M, S)$ to the receiver.

Verification (by receiver, using sender's public key):

1. Compute the hash of the received message: $h' = H(M)$.
2. Decrypt the signature using the sender's public key:

$$h = D_{\text{pub}}(S)$$

3. Compare $h$ and $h'$:
   • If $h = h'$ → the message is authentic and unaltered, and it must have come from the holder of the private key.
   • If $h \ne h'$ → the message has been tampered with or did not come from the claimed sender.

Because only the sender holds the private key, a valid signature authenticates the sender; because the signature covers the message hash, any change to $M$ breaks the match, ensuring integrity.

Authentication System

An authentication system is a mechanism that verifies the claimed identity of a user (or entity) before granting access to a system or resource. Formally, it is a 5-tuple $(A, C, F, L, S)$:

• $A$ – the set of authentication information that users present (e.g. passwords, tokens, biometrics).
• $C$ – the set of complementary information the system stores (e.g. hashed passwords).
• $F$ – the set of complementation functions $f: A \rightarrow C$ that map authentication info to complementary info.
• $L$ – the set of authentication functions $l: A \times C \rightarrow \{true, false\}$ that verify identity.
• $S$ – the set of selection functions that enable an entity to create or change the authentication/complementary information.

Challenge-Response as an Authentication System

In a challenge-response scheme, the user proves knowledge of a secret without sending the secret itself:

1. The user requests access (claims an identity).
2. The system (verifier) sends a random, unpredictable challenge (a nonce) $r$.
3. The user computes a response by applying a secret-keyed function to the challenge, e.g.

$$\text{response} = f(r, \text{secret})$$

such as an encryption $E_k(r)$ or a keyed hash (HMAC). 4. The user returns the response. 5. The system computes the expected response using its stored secret and compares it with the received response. If they match, authentication succeeds.

Advantages: The secret is never transmitted; because each challenge is fresh (a nonce), an eavesdropper cannot replay an old response. This defeats replay and sniffing attacks that affect simple password schemes.

Trust Frameworks

A trust framework defines how trust is established, distributed and managed among entities in a security system — i.e. how one party decides to believe the identity or assertions of another. The major trust frameworks/models are:

1. Direct (Peer-to-Peer) Trust – two parties trust each other directly by exchanging and verifying credentials (e.g. exchanging public keys in person). Simple but does not scale.

2. Hierarchical Trust (PKI / Certificate Authority model) – trust flows from a single root Certificate Authority (CA) down through intermediate CAs to end entities. A user trusts a certificate if it chains up to a trusted root CA. Used in X.509 PKI and TLS. Scalable but creates a single point of trust/failure.

3. Web of Trust – a decentralised model (e.g. PGP) where users sign each other's public keys. Trust is built up through chains of mutually trusting individuals rather than a central authority.

4. Bridge / Cross-Certification Trust – independent PKI hierarchies are linked by a bridge CA or by cross-certifying each other's roots, allowing users in different domains to trust one another.

5. Distributed / Federated Trust – trust is shared across multiple authorities or identity providers (e.g. SAML, OAuth federations, single sign-on), where a relying party trusts assertions issued by a federated identity provider.

Comparison: Hierarchical models are centralised and scalable but depend on the root CA; web-of-trust is decentralised and resilient but harder to manage; federated/bridge models balance scalability with cross-domain interoperability.

Zombies

A zombie is a computer that has been compromised by malware and is secretly controlled by an attacker without the owner's knowledge. The attacker uses it remotely to perform malicious actions — most commonly sending spam or participating in Distributed Denial-of-Service (DDoS) attacks. A network of many zombies is called a botnet.

Bots

A bot (short for "robot") is an automated software program that performs tasks over a network. In the security context, a malicious bot is malware that infects a host and connects it to a command-and-control (C&C) server, turning the machine into a remotely controllable agent. A collection of such bots forms a botnet, which can be commanded en masse for spam, DDoS, credential theft or click fraud.

Rootkits

A rootkit is a set of malicious software tools that gives an attacker privileged (root/administrator) access to a computer while actively hiding its own presence and that of other malware. Rootkits operate stealthily (often at the kernel level), modifying the operating system so that infected files, processes and network connections are concealed from users and antivirus tools, making them very difficult to detect and remove.

Relationship: Malware (a bot) can infect a machine and turn it into a zombie within a botnet, while a rootkit may be installed to hide that infection and maintain persistent control.

Copyright vs Patent

Both copyright and patent are forms of intellectual property protection, but they protect different things and work differently.

Summary: Copyright protects the creative expression of ideas and arises automatically, while a patent protects novel inventions and must be formally granted, lasting a shorter time.

Security Auditing Architecture

Security auditing is the process of collecting, recording and analysing system activity to detect security violations and verify that security policy is being enforced. A typical security auditing architecture consists of the following components:

1. Logger (Event Collection / Data Generation) – the component that records security-relevant events (logins, file access, privilege use, configuration changes). It decides what information to log and writes it to the audit trail. It must capture enough detail (who, what, when, where, outcome) without excessive overhead.

2. Audit Trail / Log Storage – the secure repository where logged events are stored. Logs must be protected from unauthorised modification or deletion (e.g. write-once, integrity-protected) so they can be trusted as evidence.

3. Analyzer – the component that examines the logged data for signs of policy violations or attacks. It may use signature-based detection, anomaly detection or rule-based analysis and may feed an intrusion-detection system. It can also reconfigure logging based on what it finds.

4. Notifier / Reporter – generates reports, alerts and notifications to administrators when suspicious activity or violations are detected, and produces summaries for compliance review.

Flow: Events occur in the system → the logger records them → stored in the audit trail → the analyzer processes the trail → results are presented by the notifier/reporter.

Good auditing architecture ensures accountability (actions can be traced to individuals), supports intrusion detection, and provides non-repudiable evidence for forensic investigation.

What is Risk?

In information security, risk is the potential for loss or harm when a threat exploits a vulnerability in an asset. It is commonly expressed as a function of the likelihood of a threat occurring and the impact (consequence) if it does:

$$\text{Risk} = \text{Threat} \times \text{Vulnerability} \times \text{Impact (asset value)}$$

or more simply, $\text{Risk} = \text{Likelihood} \times \text{Impact}$.

How Security Risk Analysis is Done

Security risk analysis is a systematic process to identify, assess and prioritise risks. The main steps are:

1. Asset identification – identify and value the assets to be protected (data, hardware, software, services).
2. Threat identification – determine the potential threats to each asset (e.g. malware, insider attack, natural disaster).
3. Vulnerability identification – find weaknesses that threats could exploit (e.g. unpatched software, weak passwords).
4. Likelihood assessment – estimate the probability of each threat exploiting a vulnerability.
5. Impact assessment – estimate the loss/consequence (financial, operational, reputational) if the risk materialises.
6. Risk determination – combine likelihood and impact to compute and rank each risk (qualitatively as Low/Medium/High, or quantitatively using values such as ALE = SLE × ARO).
7. Risk treatment / control recommendation – decide how to handle each risk: mitigate (apply controls), transfer (insurance), accept, or avoid.

Approaches:

• Quantitative – assigns numeric/monetary values (e.g. Annualised Loss Expectancy, $\text{ALE} = \text{SLE} \times \text{ARO}$).
• Qualitative – uses descriptive ratings (Low/Medium/High) on a risk matrix.

The output is a prioritised list of risks that guides where security resources and controls should be applied.