1. SSH: SECURE LOGIN CONNECTIONS OVER THE INTERNET
Tatu Yloenen
SSH Communications Security

2. MOTIVATION Connecting through the Internet Cheap and convenient Risky
Internet does not protect transmitted data

3. Threats from the Internet
Network monitoring
Connection hijacking: connections can be hijacked without either party noticing
Routing spoofing
DNS (domain name server) spoofing
Denial of service attacks

4. How to protect ourselves
An acceptable solution must guarantee
Authentication of both ends of the connection
Secrecy of transmitted information
Integrity of transmitted data
Secrecy of transmitted information is crucial

5. CRYPTOGRAPHY (I) 1. Conventional Cryptography
Uses same key for coding and encoding
Key could be a secret alphabet
We now use much more complex schemes and much bigger keys
Major problem is key distribution
Very hard without a trusted channel 5

6. Example Assume we have a random stream of bits:
r0 , r1 , r2 , r3 , ...
We convert our message into a bit stream:
m0 , m1 , m2 , m3 , ...
Encode the message bitwise using XOR:
ci = mi  ri for i = 1, 2, 3 , ...
Impossible to break if random bit stream is truly random and never reused 6

7. CRYPTOGRAPHY (II) 2. Public-Key Cryptography Uses two keys:
(a) A public key to encode: KP
(b) A secret key to decode: KS
It is not possible to compute KS knowing KP
The function KP = f ( KS ) is said to be hard to invert: 7

8. CRYPTOGRAPHY (II) We should have { { cleartext }KP }KS = cleartext
{ { cleartext }KS }KP = cleartext
Requires very long keys
Cannot pick an arbitrary secret key
Much slower than conventional cryptography 8

9. Example Assume A knows KP, B and B knows KP, A
A can send to B a secret message:
{ text } KP, B
A can send to B a message that is signed:
A, { text } KS, A
A can send to B a signed secret message:
{ A, { text }KS, A } KP, B 9

10. Application
Can combine conventional cryptography and public-key cryptography
A uses public-key cryptography to send to B a signed secret message containing a session key KS
A and B use this session key KS to continue their dialogue 10

11. SSH Allows Secure login connections Secure file transfer
over the Internet or other untrusted networks

12. SSH Uses cryptographic algorithms to
Authenticate both ends of the connection
Encrypt all transmitted data
Protect data integrity
Validate values returned by services such as DNS or network protocols (such as TCP)

13. Transport-level encryption
Every transmitted packet starts with random padding, followed by (optionally compressed) header and data
The entire packet is encrypted using a suitable algorithm
Packet type and data fields can be compressed with gzip before encryption
1/3 of original size

14. Integrity protection
Originally provided by including CRC32 of the packet under encryption
Found to be insufficient
Was replaced by HMAC-SHA

15. What is HMAC-SHA? (I) HMAC: Hash-based Message Authentication Code
Uses a cryptographic hash function
Any change to the hashed data will (with very high probability) change the hash value

16. What is HMAC-SHA? (II) SHA: Secure Hash Algorithm
Four different algorithms: SHA-0, SHA-1, SHA-2, and SHA-3
SHA-1
Most widely used
Fixes a flaw in SHA-0
Produces a 160-bit "digest"

17. SSH login protocol Works on top of the packet-level protocol
Step 1: The client opens a connection to the server

18. SSH login protocol Step 2: Server sends Its public RSA host key
Another public RSA key (``server key'') that changes every hour

19. SSH login protocol
The client compares the received host key against its own database of known host keys,
Can decide to
Reject keys coming from unknown hosts
Accept them and store them in its database

20. SSH login protocol Step 3: The client
Generates a 256 bit random number using a cryptographically strong RNG (session key)
Picks an encryption algorithm among those supported by the server
Encrypts the session key with RSA using both the host key and the server key
Sends the encrypted key to the server

21. The server key Changed every hour
Used to make decrypting recorded historic traffic impossible after the server key has been changed when the host key becomes compromised
Normally a 768 bit RSA key
Host key is 1024 bits

22. SSH login protocol Step 4: Server Recovers the session key
Sends an encrypted confirmation to the client
Shows client that it holds the proper private keys
Client and server can start using transport-level encryption and integrity protection

23. SSH login protocol Step 5: User starts authentication procedure
First request includes the user login name
Server replies with either
success no further authentication is needed
failure further authentication is required

24. Authentication methods
Traditional password authentication
Combination of .rhosts or hosts.equiv authentication and RSA-based host authentication
Pure RSA authentication:
Server maintains a list of users' public keys.
User requests authentication for a given key
Server responds with a challenge

25. X11 and TCP/IP Forwarding
SSH can automatically forward the connection to the user's X server over the secure channel
SSH also automatically stores Xauthority data on the server
TCP/IP forwarding works similarly
(Not covered in detail)

26. Authentication Agent SSH supports using an authentication agent
Program that runs in the user's local machine (or on a smartcard connected to it)
Agent holds the user's private RSA keys
In the Unix environment, the agent
Starts as a parent of the user's shell
Communicates with SSH using a file descriptor it shares with its children

27. 1996 Changes (Not covered) New transport layer protocol:
Better integrity checks
HMAC-MD5 and HMAC-SHA
More complete encryption of packet contents
New authentication protocol
(Not covered)

28. Performance Startup time: a few seconds Data encryption rate:
Quite good on 1995 Pentium computers

29. Security Security: Everything is encrypted Monster issue:
A user connecting to a new server or to any server from a new client will rarely verify the identity of the server before having sent her password
A Kerberos user never sends her password

30. OTHER SOLUTIONS (I) Could use one-time passwords
Use a different password at each log in
Passwords can be managed by a smart card
User must always carry it with her
Some systems also require a password to use the card and disable card after enough unsuccessful trials
Must keep card in a rigid container 30

31. OTHER SOLUTIONS (Ii) Two-factor authentication Must provide
Something you know (a password)
Something you have (a dongle or a phone)
Google two-factor authentication:
Enter name and password
Server then sends a six-digit code to your phone that you must then enter 31

32. CONCLUSION Strong cryptography Solves Internet security issues
At negligible cost