11 A) Discuss the types of attacks that are handled by
message authentication.
Message Authentication:
Message authentication ensures the integrity and authenticity of a message, verifying that it
originated from the claimed sender and hasn't been altered during transmission. This is crucial
for secure communication, preventing masquerading and ensuring data integrity
Key categories of attacks that message authentication mechanisms are designed to handle:
Modification Attacks (Content Modification):
Attackers tamper with the message data during transmission.
Message authentication uses tags/signatures that change if the message is altered,
revealing the tampering upon verification.
Masquerade Attacks (Source Fabrication):
An unauthorized entity pretends to be the legitimate sender of a message.
Message authentication verifies the sender's identity by ensuring only the rightful
sender can create a valid and verifiable authentication tag/signature.
Replay Attacks (Timing Modification):
Valid, authenticated messages are captured and later retransmitted to achieve an
unauthorized action.
While basic message authentication doesn't inherently prevent this, including time-
sensitive or unique data (like sequence numbers or nonces) within the authenticated
content allows detection.
Repudiation Attacks:
The sender falsely denies having sent a specific message (source repudiation).
Digital signatures, using the sender's private key, provide non-repudiation, offering
proof of origin that the sender cannot easily deny; MACs do not offer this due to the
shared secret.
12 A) Explain the steps involved in Kerberos protocol for
providing authentication service
The Kerberos protocol provides a robust authentication service using a trusted third party called
the Key Distribution Center (KDC). Here are the main steps involved:
1. Authentication Request (AS_REQ):
The client (user or service) sends an initial authentication request to the
Authentication Server (AS) part of the KDC.
This request includes the client's identity (username) and the identity of the Ticket
Granting Server (TGS). The request is often protected against eavesdropping but
doesn't prove the client's identity yet.
2. Ticket Granting Ticket Issue (AS_REP):
The AS verifies the client's identity, usually by checking if the provided information
matches its database (often using a pre-shared secret derived from the user's
password).
If the authentication is successful, the AS issues a Ticket Granting Ticket (TGT).
This ticket acts as a credential for the client to request service tickets later.
The AS sends the TGT to the client, encrypted using a secret key known only to the
client and the AS. This message also includes a session key (client/TGS session key) for
secure communication between the client and the TGS, encrypted with the client's
secret key.
3. Service Request (TGS_REQ):
When the client wants to access a specific service (e.g., a file server), it sends a request
to the Ticket Granting Server (TGS).
This request includes the TGT (obtained in the previous step) and an Authenticator.
The Authenticator contains the client's identity and a timestamp, encrypted using the
client/TGS session key (from the TGT). This proves the client possesses the valid TGT
and that the request is current (to prevent replay attacks). The request also specifies
the service the client wants to access.
4. Service Ticket Issue (TGS_REP):
The TGS decrypts the TGT using its secret key (shared with the AS) to verify its validity
and retrieve the client/TGS session key.
Using the session key, the TGS decrypts and verifies the Authenticator to confirm the
client's identity and the freshness of the request.
If everything is valid, the TGS issues a Service Ticket for the requested service. This
ticket contains information about the client and the service, a validity period, and a
new session key (client/server session key) for secure communication between the
client and the specific service.
The TGS sends the Service Ticket to the client, encrypted using the client/TGS session
key. The TGS_REP also includes the client/server session key, encrypted using the
client/TGS session key.
5. Service Access Request (AP_REQ):
The client sends the Service Ticket to the target service.
Along with the Service Ticket, the client also sends an Authenticator containing its
identity and a timestamp, encrypted using the client/server session key (from the
Service Ticket). This proves to the service that the client possesses a valid Service
Ticket and that the request is current.
6. Service Grant (AP_REP - Optional for Mutual Authentication):
The service decrypts the Service Ticket using its secret key (shared with the TGS) to
verify the client's identity and the ticket's validity.
The service then decrypts and verifies the Authenticator using the client/server session
key to ensure the request is legitimate and not replayed.
If successful, the service grants the client access.
Optionally, for mutual authentication, the service can send an Authenticator Reply
(AP_REP) back to the client. This reply contains a timestamp (often the client's
timestamp incremented), encrypted with the client/server session key, proving the
service's identity to the client.
These steps ensure that the client and service can authenticate each other without directly
exchanging passwords over the network. The KDC acts as a trusted intermediary, issuing tickets
that grant access based on initial authentication.
13) A Explain the SSH protocol stack in detail with a neat
diagram. Explain the SSH user authentication protocol and
connection protocol with the steps involved in message
exchanges.
SSH Protocol Stack:
SSH Definition:
SSH (Secure Shell) is a cryptographic network protocol used for operating network services
securely over an unsecured network. It provides a secure channel over an insecure network by
encrypting all traffic between the client and the server.
It is commonly used for remote command-line login and remote command execution.
SSH uses port 22 by default.
Features of SSH:
Privacy (Confidentiality): SSH encrypts all data exchanged between the client and the
server, preventing eavesdropping and ensuring that sensitive information remains private.
Integrity: SSH uses cryptographic hash functions (like MACs) to ensure that the data
transmitted has not been tampered with or altered in transit.
Authentication: SSH authenticates the server to the client (preventing man-in-the-
middle attacks) and the client to the server (verifying the user's identity).
Authorization: Once a user is authenticated, the server determines what actions the user
is allowed to perform based on their account and permissions.
Forwarding: SSH allows for secure tunneling of other TCP ports and X11 connections,
enabling secure access to other services.
Functions of SSH:
Secure remote login.
Secure file transfer (using SFTP or SCP, which often run over SSH).
Secure port forwarding (tunneling).
Sequence of Events in the SSH Transport Layer Protocol:
1. TCP Connection Establishment: The SSH client initiates a TCP connection to the SSH
server on port 22.
2. Server Identification: The SSH server sends its identification string to the client,
indicating its software version.
3. Key Exchange: The client and server negotiate and execute a key exchange algorithm
(e.g., Diffie-Hellman) to establish shared secret keys. During this phase, the server also
sends its host key to the client for authentication.
4. Server Authentication: The client verifies the server's host key (e.g., by checking a
known_hosts file or through other trust mechanisms) to ensure it's connecting to the
intended server.
5. Session Key Generation: Based on the key exchange, session keys are derived for
symmetric encryption and message authentication.
6. Encryption and Integrity Protection Setup: The client and server agree on the
encryption algorithm (e.g., AES) and the Message Authentication Code (MAC) algorithm to
be used for all subsequent communication.
7. Secure Communication Begins: All further data exchanged between the client and the
server is encrypted and protected for integrity using the agreed-upon algorithms.
14 B)Describe the major security concerns related to
mobile device security.
Mobile Device
A portable computing device like a smartphone or tablet used for communication,
browsing, and app usage.
Runs on mobile operating systems (e.g., Android, iOS) with wireless connectivity like Wi-Fi,
Bluetooth, and cellular networks.
Mobile Device Security
Measures and technologies used to protect mobile devices from threats like data theft,
malware, and unauthorized access.
Includes encryption, authentication, app control, and regular software updates.
Major Security Concerns Related to Mobile Device Security
1. Data Leakage
Caused by malicious apps, unsecured storage, or improper data sharing.
Sensitive info like contacts, location, passwords can be leaked.
2. Unsecured Wireless Connections
Public Wi-Fi can be used by attackers for man-in-the-middle (MITM) attacks.
Data can be intercepted if not encrypted.
3. Malware and Malicious Apps
Apps may contain spyware, ransomware, or trojans.
Often spread through third-party app stores or phishing links.
4. Physical Theft or Loss
If the device is not encrypted or locked, data can be stolen easily.
Leads to identity theft or data breaches.
5. Outdated Software
Devices with old OS versions may have unpatched vulnerabilities.
Hackers exploit these to gain access.
6. Insecure App Permissions
Apps may ask for unnecessary permissions.
Can misuse camera, microphone, SMS, or contacts.
7. Weak Authentication
Use of simple PINs or no screen lock.
Increases risk of unauthorized access.
8. Lack of Encryption
Without encryption, stored and transmitted data can be read by attackers.
9. Bluetooth and NFC Exploits
Attackers can use Bluetooth or NFC to send malicious data or connect silently.
10. Phishing Attacks
Users may be tricked into entering credentials on fake websites.
SMS and email are common phishing vectors on mobile.
15 B) With a neat diagram explain the various components
of IoT Security framework
IoT Security Framework – Components
The IoT (Internet of Things) security framework consists of multiple layers that work together to
secure devices, data, networks, and communication.
Components of IoT Security Framework
1. Device Security
Secures the physical device and its firmware.
Includes secure boot, firmware validation, and tamper detection.
2. Network Security
Protects data in transit between devices and cloud.
Includes firewalls, intrusion detection/prevention systems (IDS/IPS), and VPNs.
3. Application Security
Ensures IoT apps are free from vulnerabilities.
Involves code reviews, API security, and secure development practices.
4. Data Security and Privacy
Protects data at rest and in transit using encryption.
Implements data anonymization and access control.
5. Authentication and Access Control
Verifies identity of users/devices.
Uses passwords, biometrics, digital certificates, or tokens.
6. Security Monitoring and Management
Continuous monitoring for threats and vulnerabilities.
Includes logging, alerts, and automated responses.
7. Cloud Security
Protects cloud platforms that manage or store IoT data.
Involves identity management, encrypted storage, and access controls.
16 A. RSA Decryption
We are given:
Ciphertext ( C = 10 )
Public key ( e = 5 ), ( n = 35 )
To find the plaintext ( M ), we need to use RSA decryption. The RSA decryption formula is:
M = Cd mod n
Where:
( C ) is the ciphertext
( d ) is the private key
( n ) is the modulus (same as in the public key)
( M ) is the plaintext
Step 1: Find ( d ) (private key)
To find ( d ), we need to calculate the modular inverse of ( e ) modulo φ(n) , where φ(n) is the
Euler's totient function of ( n ).
1. Find the factors of ( n = 35 ):
35 = 5 × 7
2. Calculate φ(n):
φ(35) = (5 − 1) × (7 − 1) = 4 × 6 = 24
3. Find ( d ), the modular inverse of ( e = 5 ) modulo ( 24 ): We need to solve for ( d )
such that:
e×d≡1 (mod 24)
In other words, we need to find ( d ) such that ( 5d \equiv 1 \pmod{24} ).
By testing values, we find that ( d = 5 ) satisfies the equation:
5 × 5 = 25 ≡ 1 (mod 24)
Thus, ( d = 5 ) is the private key.
Step 2: Decrypt the ciphertext
Now, we use the formula for RSA decryption:
M = Cd mod n
Substitute the values:
M = 105 mod 35
We first calculate 105 mod 35:
105 = 100000
Now, compute the modulus:
100000 mod 35 = 100000 − (35 × 2857) = 100000 − 99995 = 5
Thus, the plaintext ( M = 5 ).
Final Answer:
The plaintext ( M = 5 ).
