Assigment 2

Angabe

This lesson

Java Remote Method Invocation - RMI

Secure handshakes with Java Cryptography API - JCA

Hash based message authentication - HMAC

Extension of Assignment 1 by

Decentralized naming service

“opportunistic encryption” for secure DMAP channels

allowing users the validation of integrity of messages

Message client for users (so that using the mail service gets easier)

Version 2.0 of DMAP and DMTP protocols

Decentralized naming space

Previously: looking up in config file.

Now a network that must be queried by transferservers.

Top level domain hosted by root nameserver .

Each subdomain / zone is hosted by exactly one nameserver.

We use the RMI registry for bootstrapping that provides a remote object that is known and can be called by new nameservers via RMI.

To connect to a network, a peer needs to know the address of at least one other peer already connected to the network.

The RMI registry has a well-known IP address and can thus be accessed by any peer.

Below we have vienna.earth.planet and earth.planet , mars.planet .

Registration of nameservers (and mailbox servers)

Done recursively.

Registration request is sent to root and then is forwarded to the parent server.

Domain lookup

Done iteratively.

Transfer server looks up mailbox server IP.

Here we want the IP of @vienna.earth.planet

Command-line interface

nameservers prints list of nameservers (zones as child nodes)

addresses prints stored mailbox servers

shutdown

Secure DMAP channel

Currently: TCP without encryption (even when sending passwords via login )

Opportunistic encryption for DMAP channels by optionally allowing to encrypt.

https://en.m.wikipedia.org/wiki/Opportunistic_TLS

Handshake protocol

client establishes connection to DMAP server.C (plain): startsecure
S (plain): ok <component-id of server>
client then looks up servers public key via its component-id.C (RSA): ok <client-challenge> <secret-key> <iv>
client wants server to prove its identity
(eveything encrypted with the servers public key)
- challenge: random 32 byte number
- secret-key: for AES (symmetrical is faster than asymmetrical)
- initialization-vector: for AESS (AES): ok <client-challenge>
server returns decrypted challenge from client
C (AES): ok

Message integrity verification

Client side application allows sigining and verifying messages

using encryped hash message authentication codes HMAC.

The sender and recipient of a message share a common-secret-key (inserted by message client).

Sender: creates 32-byte hash from message, sent via hash command.

Recipient: calculates hash with common-secret-key and and compares it with the passed of the hash command.

Message client

Standalone command-line application configured for a specific user.

Stores the user username, password, email address, transfer and mailbox server details in a property file.

Allows:

encryption, decryption

signing, verifying messages

Commands

inbox Composition of DMAP list and show <id>

delete <message-id> deletes

verify <message-id> verifies

msg <to> "<subject>" "<data>" establishes DMTP connection, sends message

shutdown logs client out from DMAP session

Protocol Extensions

DMAP 2.0

All output lists end with an “ok” so that client-application knows when lines end.

startsecure secure connection

show must now also show hash fields

DMTP 2.0

hash <message-hash> attaches hash to a message (calculated by client)

Abgabe

Nameserver

Each nameserver is represented by a remote object that can be called via the network.

root-server bound to RMI registry, hosted by the server itself (known IP)

accessible by every other server.

zone-server stored in-memory by parents.

Nameservers are

called by mailbox-servers to register mail domains

called by transfer-servers to lookup domains

called by other nameservers to register new zones

Parameters

root_id name that the remote object is bound to

registry.host host name or IP address of RMI registry

registry.port port of RMI registry

domain domain managed by this nameserver → the root does not have this