Secure Email & Identity Federation

TAKEAWAYS:

• Email encryption (S/MIME/PGP) protects content and sender identity using public-key cryptography.
• Identity management (LDAP, OAuth) centralizes authentication while allowing third-party access.
• Federated identity (SAML/OpenID) enables single sign-on across services without sharing passwords.
• Phishing and spoofing remain threats; multi-factor authentication (MFA) mitigates risks.
• NEPSE and Daraz use OAuth for secure third-party logins; eSewa uses TLS for transaction security.
• Exam questions test protocol flows, attack scenarios, and configuration steps.

1. Secure Email Protocols

Email is a primary attack vector for phishing, spoofing, and data leaks. Secure email protocols encrypt messages and verify sender authenticity.

1.1 S/MIME (Secure/Multipurpose Internet Mail Extensions)

S/MIME uses public-key cryptography to encrypt email content and digitally sign messages.

How it works:

1. Recipient’s public key is embedded in the recipient’s digital certificate (issued by a CA like DigiCert).
2. Sender encrypts the email with the recipient’s public key.
3. Sender signs the email with their private key.
4. Recipient decrypts with their private key and verifies the signature using the sender’s public key.

Visual: S/MIME Message Flow

sequenceDiagram
    participant Sender
    participant CA
    participant Recipient
    Sender->>CA: Requests digital certificate (public key)
    CA-->>Sender: Issues certificate (public key)
    Sender->>Recipient: Sends encrypted (public key) + signed (private key) email
    Recipient->>Recipient: Decrypts (private key) and verifies signature (sender’s public key)

Advantages:

• End-to-end encryption (only sender and recipient can read).
• Non-repudiation (digital signatures prove sender identity).

Disadvantages:

• Requires certificate management (expires, revocation).
• Complex setup for users (key exchange, trust chains).

Worked Example: NEPSE Trade Confirmation NEPSE uses S/MIME to send encrypted trade confirmations to brokers. If a broker receives a signed email from NEPSE, they know it’s authentic and unaltered.

1.2 PGP (Pretty Good Privacy)

PGP is an open-source alternative to S/MIME, widely used for personal email security.

Key Components:

• Public Key: Shared with anyone to encrypt messages.
• Private Key: Kept secret to decrypt messages and sign emails.
• Web of Trust: Users manually verify each other’s keys (unlike CA-based S/MIME).

Visual: PGP Key Exchange

Advantages:

• No reliance on CAs (decentralized trust).
• Works with any email client (Gmail, Outlook).

Disadvantages:

• Manual key verification can be error-prone.
• No built-in revocation mechanism (unlike CRLs in S/MIME).

Worked Example: WhatsApp Encrypted Messages WhatsApp uses PGP-like encryption (Signal Protocol) for end-to-end encrypted chats. Similarly, PGP can secure email threads between activists or journalists.

2. Identity Management Systems

Identity management (IdM) authenticates users and controls access to resources (e.g., emails, apps).

2.1 LDAP (Lightweight Directory Access Protocol)

LDAP stores user credentials in a hierarchical database (e.g., Active Directory).

Visual: LDAP Directory Structure

graph TD
    A["Active Directory Root"]
    B["OU: Departments"]
    C["OU: Students"]
    D["OU: Faculty"]
    A --> B
    B --> C
    B --> D
    C --> E["User: Ram Thapa"]
    D --> F["User: Prof. Hari Prasad"]

LDAP hierarchical structure (Active Directory example) How it works:

1. User logs in via LDAP (e.g., ldap://directory.example.com).
2. LDAP queries the database for credentials.
3. If valid, the user gains access to authorized resources.

Advantages:

• Centralized authentication (single sign-on).
• Scalable for large organizations (e.g., NTC uses LDAP for employee logins).

Disadvantages:

• Single point of failure (if LDAP server crashes, no logins).
• Passwords are stored (risk if database is breached).

Worked Example: NTC Employee Logins NTC uses LDAP to manage employee access to internal systems. If an employee’s password is compromised, LDAP admins can revoke access immediately.

2.2 OAuth 2.0 (Open Authorization)

OAuth allows third-party access without sharing passwords. Used by eSewa, Google, and Facebook.

How it works (Authorization Code Flow):

1. User clicks "Login with Google" on Daraz.
2. Daraz redirects to Google’s OAuth server.
3. Google authenticates the user and returns an authorization code.
4. Daraz exchanges the code for an access token.
5. Daraz uses the token to fetch user data (e.g., profile) from Google.

Visual: OAuth Flow

sequenceDiagram
    participant User
    participant Daraz
    participant Google
    User->>Daraz: Clicks "Login with Google"
    Daraz->>Google: Redirects to OAuth login
    Google->>User: Asks for permission
    User->>Google: Approves access
    Google-->>Daraz: Returns authorization code
    Daraz->>Google: Exchanges code for access token
    Google-->>Daraz: Returns access token
    Daraz->>Google: Fetches user data (e.g., email)

Advantages:

• No password sharing (reduces phishing risk).
• Granular permissions (e.g., "Let Daraz access your address only").

Disadvantages:

• Token theft can lead to unauthorized access.
• Requires secure token storage (e.g., HTTP-only cookies).

Worked Example: eSewa Third-Party Logins eSewa allows users to link their accounts to banks (e.g., NMB) using OAuth. When a user logs into eSewa via NMB, NMB never sees their eSewa password—only an OAuth token.

3. Federated Identity (Single Sign-On)

Federated identity allows users to log in once and access multiple services (e.g., Google, Microsoft, Ncell).

3.1 SAML (Security Assertion Markup Language)

SAML uses XML-based tokens to exchange authentication data between Identity Providers (IdP) and Service Providers (SP).

Visual: SAML Flow

sequenceDiagram
    participant User
    participant SP (e.g., Daraz)
    participant IdP (e.g., Google)
    User->>SP: Requests access to Daraz
    SP->>IdP: Redirects to Google login
    IdP->>User: Asks for credentials
    User->>IdP: Logs in
    IdP-->>SP: Returns SAML assertion (signed XML token)
    SP->>SP: Validates token and grants access

Key Components:

• Assertion: XML document proving user identity.
• Session: Temporary token for SP access.

Advantages:

• No password sharing between services.
• Works with enterprise SSO (e.g., Ncell employees logging into multiple apps).

Disadvantages:

• Complex setup (requires IdP and SP integration).
• SAML tokens can be large (slow for mobile apps).

Worked Example: Ncell Employee Portal Ncell uses SAML to let employees log into HR, email, and payroll systems with a single Google Workspace account. The HR portal acts as the SP, while Google is the IdP.

3.2 OpenID Connect (OIDC)

OIDC is an OAuth 2.1 extension for authentication (not just authorization).

How it differs from SAML:

Visual: OIDC JWT Structure

Advantages:

• JWTs are compact and easy to parse.
• Works well for mobile/web apps (e.g., Pathao uses OIDC for user logins).

Disadvantages:

• No built-in session management (unlike SAML).
• JWTs can be stolen if not secured properly.

Worked Example: YouTube Login via Google When you log into YouTube with a Google account, YouTube acts as the SP, Google as the IdP, and OIDC returns a JWT token. This token is used to authenticate your YouTube session.

4. Threats and Mitigations

Visual: DMARC Protection Flow

sequenceDiagram
    participant Sender
    participant Mail Server
    participant Receiver
    Sender->>Mail Server: Sends email with SPF/DKIM/DMARC headers
    Mail Server->>Receiver: Checks DMARC policy ("reject" if failed)
    Receiver->>Receiver: Quarantines or rejects spoofed emails

5. Real-World Applications

In the real world

1. eSewa (Nepal):

   • Uses OAuth 2.0 to let users link their bank accounts (e.g., NMB, Global IME) without sharing passwords. When a user pays via eSewa, the bank’s OAuth server validates the transaction without exposing credentials.

2. Google Workspace (Global):

   • Implements SAML and OIDC for enterprise SSO. Companies like Ncell use Google as an IdP to let employees access internal tools (e.g., Slack, Microsoft Teams) with a single sign-on.

3. Daraz (Nepal):

   • Uses OAuth for third-party logins (e.g., "Login with Facebook"). When a user logs in via Facebook, Daraz receives a temporary access token from Facebook’s OAuth server, which it uses to fetch the user’s profile data.

4. NEPSE (Nepal):

   • Encrypts trade confirmations with S/MIME to prevent tampering. Brokers can verify that the email is genuinely from NEPSE and hasn’t been altered.

6. Exam Tip

• Protocol Flows: Always draw sequence diagrams for OAuth, SAML, or S/MIME. Examiners love clear flows.
• Attack Scenarios: Know how phishing exploits weak email security (e.g., missing SPF/DKIM).
• Configuration: For LDAP or OAuth, explain how you’d set up a user’s permissions (e.g., "Grant read-only access to Google Calendar").
• Comparisons: Compare SAML vs. OIDC, or S/MIME vs. PGP, in a table (as shown above).
• Real-World Tie-Ins: Relate answers to Nepali examples (e.g., "How would Ncell implement SAML for its employees?").

Example Exam Question: "Explain how OAuth 2.0 secures third-party logins like those used by eSewa. Draw the flow and discuss a potential attack if tokens are not short-lived."

Model Answer Approach:

1. Draw the OAuth flow (as above).
2. Explain authorization code and access token.
3. Mention token expiration and HTTP-only cookies.
4. Describe token theft attack and how short-lived tokens mitigate it.