Real-time Communication Security Introduction

Introduction
Module-4 (Real-time Security and Application Layer
Security)

Real-time communication security – Perfect Forward A real-time protocol negotiates interactively to authenticate each other
Secrecy (PFS), Denial-of-Service protection, Endpoint and establish a session key in contrast to a protocol such as email in
which one party prepares a message that can later be decrypted
identifier hiding, Live partner reassurance.
and authenticated by the intended recipient.
➠ e.g., IPsec, SSL/TLS, and SSH.
Hypertext Transfer Protocol Secure (HTTPS) –
Connection initiation, Closure. Secure Shell (SSH) – At a minimum, the protocols provide mutual authentication between
Transport layer protocol, User authentication protocol, Alice and Bob and establish a session key for cryptographic
Connection protocol. protection of the subsequent conversation.

Secure Electronic Transaction (SET) – Overview, The conversation protected with that session key is known as a
security association
Features, Participants, Dual signature, Payment
processing.
2 / 12

Real-time Communication Security What Layer? Real-time Communication Security What Layer?

What Layer? What Layer?

SSL/TLS and SSH are said to be “implemented at layer 4”,

whereas IPsec is said to be “implemented at layer 3.

IP stacks (i.e., TCP/UDP/IP...) are implemented in the OS kernel

SSL and SSH are built above TCP in the user space
➠ easy to deploy, but applications have to be (minimally)
modified

IPSec is implemented inside the OS

➠ OS needs to be changed, applications may remain unchanged
➠ changes are necessary to take full advantage of IPSec
e.g., to authenticate a user instead of the IP address

3 / 12 3 / 12
 Real-time Communication Security Perfect Forward Secrecy Real-time Communication Security Perfect Forward Secrecy

Perfect Forward Secrecy Perfect Forward Secrecy

Perfect forward secrecy:
A protocol is said to have perfect forward secrecy (PFS) if it is impossible
for an eavesdropper (Sam) to decrypt a conversation between Alice and
Bob even if Sam records the entire encrypted session, and then
subsequently breaks into both Alice and Bob and steals their long-term
secrets.
The trick to achieving perfect forward secrecy is to generate a temporary
session key, not derivable from information stored at the node after the
session concludes, and then forget it after the session concludes.
If the session will last for a long time, it is common to generate and forget
keys periodically so that even if Sam seizes Alice’s and Bob’s computers
while the conversation is still going on, he will not be able to decrypt
messages received before the last key rollover.

Diffie-Hellman for perfect forward secrecy using signature keys

4 / 12 4 / 12

Real-time Communication Security Perfect Forward Secrecy Real-time Communication Security Perfect Forward Secrecy

Perfect Forward Secrecy Perfect Forward Secrecy...

It uses Diffie-Hellman to agree on a session key, which

achieves perfect forward secrecy assuming both sides generate an
unpredictable DiffieHellman private number and forget both the
private number and the agreed-upon session key after the session Do they have PFS?:
ends. Also, each side signs the Diffie-Hellman quantity to foil a Alice and Bob exchange messages encrypted with the peer’s public key
man-in-the-middle attack. Alice and Bob communicate using the session key issued by a KDC
In the first two messages, each side identifies itself, and Alice picks a session key, encrypts it with Bob’s public key, then signs
supplies a Diffie-Hellman value signed by its private key. In the and sends it to Bob
next two messages, each side proves knowledge of the agreed-
upon Diffie-Hellman value by sending a hash of it, with each side
sending a different hash. If each side forgets g^ab mod p and its
private Diffie-Hellman number (a or b) after the session, there is
no way for anyone to reconstruct g^ab mod p from knowledge of
both long-term private keys and the entire recorded conversation.
4 / 12 5 / 12
 Real-time Communication Security Denial-of-service Protection Real-time Communication Security Denial-of-service Protection

Denial-of-service Protection Denial-of-service Protection

To protect against DoS, avoid significant computation or saving states
until the initiator is proved to be reachable

Stateless cookie
• The Photuris (an early key management protocol for Ipsec) cookie is a number
chosen by Bob, and unpredictable to the side initiating communication with Bob.
• When Bob receives a connection initiation from IP source address S, Bob sends
this number, in the clear, to the IP address S.
• Bob does no significant computation until he receives the same cookie back from
that IP address.
• This assures that the initiator can receive packets sent to the IP address from
which it claims to be transmitting.
• The Photuris protocol provided for stateless cookies. The idea is to have the
cookie be a function of the IP address and a secret known to Bob, so that Bob can
Stateless cookie protocol
calculate what cookie he would have sent to a particular IP address.
6 / 12 6 / 12

Real-time Communication Security Denial-of-service Protection Real-time Communication Security Endpoint Identifier Hiding

Denial-of-service Protection: Puzzles Endpoint Identifier Hiding

Endpoint identifier hiding: to hide the identities of the communicating

parties from eavesdroppers
Bob asks Alice to do more computation in order to connect To achieve EIH:
➠ e.g., “what 27-bit number has a hash of x?” • A mechanism for accomplishing this is to first do an “anonymous”
➠ verifying a puzzle should be fast and simple Diffie-Hellman exchange, which establishes an encrypted tunnel, but
Problems: to an unknown endpoint. The tunnel might have a man-in-the-
➠ difference in the computational powers for the clients middle, since you have not authenticated the other side (indeed you
➠ not effective against distributed DoS (e.g., botnet) don’t even know who the other side is claiming to be). After the
anonymous Diffie-Hellman exchange establishes a key, the two
parties divulge their identities, encrypted with the anonymous Diffie-
Hellman key.
An active attacker doing a man-in-the middle attack would be detected
at this point, after having discovered the endpoint identities.
7 / 12 8 / 12
 Real-time Communication Security Endpoint Identifier Hiding Real-time Communication Security Endpoint Identifier Hiding

Endpoint Identifier Hiding Endpoint Identifier Hiding

In this protocol an active attacker will be able to

discover Alice’s identity, but not Bob’s. It is easy to
arrange instead to hide Alice’s identity .
If Alice and Bob know in advance to whom they will be
talking then a protocol based on a shared secret key will
hide both identities.
This is accomplished by authenticating based on
the secret key and not sending identities at all .
If Alice already knows Bob’s public encryption key, it is
possible to hide both identities from active attackers.

8 / 12 8 / 12

Real-time Communication Security Live Partner Reassurance Real-time Communication Security Live Partner Reassurance

Live Partner Reassurance Live Partner Reassurance

If Trudy can replay messages from previous conversation negotiations,

Replay attack: Trudy replays messages from previous conversations
she might be able to get Bob to waste space on a connection, or worse yet, she
➠ replayed message may cause Bob to repeat some actions might be able to replay the subsequent data messages and, even if she can’t
Use a random nounce for each connection to prevent replay attacks decrypt the conversation, she might be able to cause Bob to repeat actions. For
➠ e.g., set session key to K = hash(N, gab mod p) instance, when Bob (an ATM machine) talked to Alice, she might have
➠ what is the difference from a cookie? requested Bob to put $100 into the money tray, as in Protocol 14-5. An hour
later, if Trudy replays Alice’s messages, it is important that Bob realize that this
is not a conversation with the live Alice.
If Bob chose a different b in each Diffie-Hellman exchange, then there
wouldn’t be a problem, but it is computation intensive to compute gb, so it
might be nice to be able to reuse b. A way to allow Bob to reuse b and avoid
replay attacks is for Bob to choose a nonce for each connection attempt, and
have the session key be a function of the nonce as well as the Diffie-Hellman
key. So the protocol might be modified to look like Protocol 14-6. Here the
session key is a function of the nonce N as well as the Diffie-Hellman value.

Zhi Wang (FSU) 9 / 12 9 / 12

 Real-time Communication Security Session Resumption

Session Resumption
This seems similar to a cookie, but it is desirable for a cookie to be
stateless, so that Bob does not have to keep state until he’s at least
sure the other end can listen at the IP address it claims to be sending
from. With the most straightforward implementation of a stateless
cookie, the cookie will be reused, so wouldn’t work as a nonce. It is
Session resumption: bypass the initial public key authentication if Bob
possible to design a protocol that will allow something to work both has recently authenticated Alice and established a session key
as a nonce and as a stateless cookie (see Homework Problem 10).
Example:
Note that we’ve only ensured that Bob knows it’s the live Alice (and Alice sends Bob Xab = [{S}Bob ]Alice , encrypted and signed session key
not replayed messages). How would Alice know it’s the real Bob? If ➠ if Bob saves Alice’s last Xab and Xab = Xab, use the last S
Alice chooses a different a each time, and if Alice receives proof ➠ otherwise, Bob verifies and decrypts Xab to get S
from the other side that it knows K (for instance, by acting on her
request, which was encrypted with K), then she knows it’s the real
Bob. But suppose Alice, like Bob, would like to reuse a to save
herself from computing ga mod p (see Homework Problem 11)

10 / 12

Real-time Communication Security Plausible Deniability

Plausible Deniability
Another trick is the ability to bypass the initial expensive public
key authentication if the server has recently authenticated the client
and established a shared secret session key. In Lotus Notes, Bob (the
server) has a secret S that he shares with nobody, and changes Plausible deniability: to design the protocol so there is a lack of evidence
periodically (once a month). After Bob authenticates Alice, he sends her proving that two parties talked
a secret, SAlice-Bob, which is a hash of her name and S, encrypted with Does the following protocol have plausible deniability?
her public key. Until Bob changes S, he’ll give Alice the same SAlice-Bob
each time she is successfully authenticated. Alice and Bob authenticate with a shared secret?
The actual session key (used for encryption and integrity ➠ yes, the session can be forged (solely) by Alice or Bob
protection) is a function of SAlice-Bob and nonces sent by each side. If Alice and Bob authenticate using public encryption key?
Alice shows knowledge of the SAlice-Bob that would result from ➠ yes, anyone can make up a conversation
hashing S and her name, then Bob assumes he’s authenticated her in Alice and Bob authenticate by signing the other’s identity?
the recent past, and they skip the expensive public key operations. If ➠ no, only Alice or Bob can access its signature key
Bob has switched Ss, then Alice’s attempt to bypass the expensive
authentication step will fail, and Alice and Bob will start from the
beginning exchanging certificates, signing things, etC

11 / 12
If a protocol involves having Alice sign something containing Bob’s name,
then it offers proof that Alice intentionally talked to Bob (though it still
gives no indication of what they talked about). In some cases Alice would
like to assure Bob that it is her, but not provide proof that she talked to
Bob. If Alice and Bob are authenticating each other based on a shared
secret, then there is no way to prove to a third party that Alice and Bob
communicated with each other, because the entire conver- sation could
have been constructed by Alice or Bob. If Alice and Bob authenticate each
other using public encryption keys, anyone could create an entire
conversation that looks like a conversation between Alice and Bob (e.g.,
consider Protocol 14-7, and change the first two messages from being
signed by the sender to being encrypted with the recipient’s public key.
No knowledge of either side’s private key is required to create such
messages). If Alice and Bob authenticate each other using public
signature keys, then it is possible to create a protocol in which each signs
information including the other’s identity, in which case there is no
plausible deniability. But it is also possible to avoid signing the other
side’s identity, and therefore preserving plausible deniability (see
Protocol 14-7).

What is SET?
Module-4 (Real-time Security and Application Layer Security)
• Real-time communication security – Perfect Forward • Secure Electronic Transaction or SET is a system which
Secrecy (PFS), Denial-of-Service protection, Endpoint ensures security and integrity of electronic transactions
identifier hiding, Live partner reassurance. done using credit cards.
• Hypertext Transfer Protocol Secure (HTTPS) – Connection • SET is not some system that enables payment but it is a
initiation, Closure. Secure Shell (SSH) – Transport layer security protocol applied on those payments.
protocol, User authentication protocol, Connection
protocol. • It uses different encryption and hashing techniques to
• Secure Electronic Transaction (SET) – Overview, Features, secure payments over internet done through credit
Participants, Dual signature, Payment processing. cards.
1 2
 Who all uses it?
• Visa • SET protocol restricts revealing of
• Mastercard • Credit card details to merchants and
• Microsoft • Order details to banks !!
• NetScape ....

3 4

General Scenario Requirements in SET

• It has to provide mutual authentication i.e., cardholder
authentication by confirming if the customer is intended
user or not and merchant authentication.
• It has to keep the PI (Payment Information) and OI (Order
Information) confidential by appropriate encryptions.
• It has to be resistive against message modifications i.e., no
changes should be allowed in the content being
transmitted.
• SET also needs to provide interoperability and
make use of best security mechanisms.
5 6
 Key Features of SET Key Features of SET

7 8

Participants in SET
1. Cardholder – customer
2. Issuer – customer financial institution
3. Merchant-person or organization that has
services or goods to sell to customer
4. Acquirer – Merchant financial institution
5. Certificate authority – Authority which follows
certain standards and issues certificates(like
X.509V3) to all other participants.
9 10
 SET TRANSACTIONS
• 1. Customer Opens An Account: Customer obtains a credit card account • 5. Merchant is Verified: In addition to the order form, the merchant sends
with a bank that supports electronic payment and SET. a copy of the certificate so that the customer can verify that he or she is
• 2. Customer Receives A Certificate: After suitable verification of identity, dealing with a valid store.
the customer receives an X.509v3 digital certificate signed by the bank. • 6. Order and Payment are Sent: Customer sends both order and payment
• 3. Merchants Have Own Certificates: A merchant who accepts a bank card information to merchant along with customer’s certificate. The order
must be in possession of two certificates for the two public keys owned by confirms the purchase of items in the order form. The payment contains
the merchant:One for signing messages,One for key exchange credit card details. The payment information is encrypted so that it cannot
• 4. Customer Places An Order: Customer send a list of items to be be read by the merchant. The customer’s certificate enables the merchant
purchased to the merchant, who returns an order form containing the list to verify the customer.
of items to be purchased to the merchant. Merchant returns an order • 7. Merchant Requests Payment Authorization: Merchant sends the
form containing the list of items, their price, a total price, and an order payment information to the payment gateway. This requests authorization
number. that the customer’s available credit is sufficient for this purchase.

11 12

Dual Signature
• 8. Merchant Confirms Order: Merchant sends a • The dual signature is a concept introduced with SET,
confirmation of the order to the customer. which aims at connecting two information pieces
• 9. Merchant Provides Goods or Service: meant for two different receivers :
Merchant ships the goods or provides the service Order Information (OI) for merchant
to the customer.
Payment Information (PI) for bank
• 10. Merchant Requests Payment: Request is sent
to payment gateway to handle payment
processing
13 14
Dual Signature
How to make Dual Signature (DS)?

PI stands for payment information

OI stands for order information
PIMD stands for Payment Information Message Digest
OIMD stands for Order Information Message Digest
15 POMD stands for Payment Order Message Digest16

17 18
 Purchase Request Generation Purchase Request Generation
• Before the Purchase Request exchange begins, the cardholder has completed 3.Purchase Request:
browsing, selecting, and ordering. For this purpose, the cardholder generates a one-time symmetric encryption key, Ks. The
message includes the following:
• The purchase request exchange consists of four messages:
• 1.Initiate Request :In order to send SET messages to the merchant, the cardholder must have a • 1. Purchase-related information.
copy of the certificates of the merchant and the payment gateway. The customer requests the This information will be forwarded to the payment gateway by the merchant and consists of
certificates in the Initiate Request message, sent to the merchant. This message includes the brand of • Payment Information (PI)
the credit card that the customer is using. The message also includes an ID assigned to this • Dual Signature
request/response pair by the customer and a nonce used to ensure timeliness.
• Order Information Message Digest (OIMD)
• 2.Initiate Response :The response includes the nonce from the customer, another nonce for the (All of these items are encrypted with Ks)
customer to return in the next message, and a transaction ID for this purchase transaction. In addition to • The digital envelope. This is formed by encrypting Ks with the payment gateway's public
the signed response, the Initiate Response message includes the merchant's signature certificate and the key-exchange key. It is called a digital envelope because this envelope must be opened
payment gateway's key exchange certificate. (decrypted) before the other items listed previously can be read. The value of Ks is not
The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and made available to the merchant. Therefore, the merchant cannot read any of this
then creates the OI and PI. The transaction ID assigned by the merchant is placed in both the OI and PI. payment-related information.

19 20

Purchase Request Generation Purchase Request Generation

• 2. Order-related information. • 4. Purchase Response : The Purchase Response message
This information is needed by the merchant and consists of
includes a response block that acknowledges the order and
- The OI references the corresponding transaction number. This block is
- The dual signature, calculated over the PI and OI, signed with the customer's private signature signed by the merchant using its private signature key. The block
key
and its signature are sent to the customer, along with the
- The PI message digest (PIMD).
merchant's signature certificate. When the cardholder software
- The PIMD is needed for the merchant to verify the dual signature. Note that the OI is sent in
the clear.
receives the purchase response message, it verifies the
• 3. Cardholder certificate.
merchant's certificate and then verifies the signature on the
This contains the cardholder's public signature key. It is needed by the merchant and by the
response block. Finally, it takes some action based on the
payment gateway. response, such as displaying a message to the user or updating a
database with the status of the order.
21 22
Purchase Request
Generation Purchase Request Validation on
capture token
Merchant Side

23 24

Purchase Request Validation on

Bank Side
PAYMENT PROCESS
 In two steps:
• Payment authorization
• Payment capture
• Payment Authorization
During the processing of an order from a cardholder, the merchant authorizes the
transaction with the payment gateway. The payment authorization ensures that the
transaction was approved by the issuer. This authorization guarantees that the
merchant will receive payment; the merchant can therefore provide the services or
goods to the customer. The payment authorization exchange consists of two
messages: Authorization Request and Authorization response.

25 26
 PAYMENT PROCESS - Payment Authorization PAYMENT PROCESS - Payment Authorization
The merchant sends an authorization request message to 2. Authorization-related information: This information is
the payment gateway consisting of the following: generated by the merchant and consists of :
1. Purchase-related information - An authorization block that includes the transaction ID, signed with the
merchant's private signature key and encrypted with a one-time symmetric
» PI key generated by the merchant
» Dual signature calculated over the PI & OI and signed with - A digital envelope. This is formed by encrypting the one-time key with the
payment gateway's public key-exchange key.
customer’s private key.
3. Certificates
» The OI message digest (OIMD)
» Cardholder’s signature key certificate
» The digital envelop » Merchant’s signature key certificate
» Merchant’s key exchange certificate
27 28

PAYMENT PROCESS - Payment Capture

PAYMENT PROCESS - Payment Authorization
• To obtain payment, the merchant engages the payment gateway in a payment capture transaction,
Having obtained authorization from the issuer, the payment gateway returns an Authorization consisting of a capture request and a capture response message.
Response message to the merchant. It includes the following elements: • For the Capture Request message, the merchant generates, signs, and encrypts a capture request
1. Authorization-related information. Includes an authorization block, signed with the block, which includes the payment amount and the transaction ID. The message also includes the
encrypted capture token received earlier (in the Authorization Response) for this transaction, as well
gateway's private signature key and encrypted with a one-time symmetric key generated by as the merchant's signature key and key-exchange key certificates.
the gateway. Also includes a digital envelope that contains the one-time key encrypted with
• When the payment gateway receives the capture request message, it decrypts and verifies the
the merchants public key-exchange key. capture request block and decrypts and verifies the capture token block.
2. Capture token information. This information will be used to effect payment later. This block • It then creates a clearing request that is sent to the issuer over the private payment network. This
is of the same form as (1), namely, a signed, encrypted capture token together with a digital request causes funds to be transferred to the merchant's account..
envelope. This token is not processed by the merchant. Rather, it must be returned, as is, • The gateway then notifies the merchant of payment in a Capture Response message. The message
with a payment request. includes a capture response block that the gateway signs and encrypts. The message also includes
3. Certificate. The gateway's signature key certificate. the gateway's signature key certificate. The merchant software stores the capture response to be
used for reconciliation with payment received from the acquirer.

29 30
Module-4 (Real-time Security and
HTTPS
Application Layer Security)
 Real-time communication security –  HTTPS (HTTP over SSL)
Perfect Forward Secrecy (PFS), Denial-of-
 combination of HTTP & SSL/TLS to secure communications
Service protection, Endpoint identifier between browser & server
hiding, Live partner reassurance.
 documented in RFC2818
 Hypertext Transfer Protocol Secure  no fundamental change using either SSL or TLS
(HTTPS) – Connection initiation, Closure.
 use https:// URL rather than http://
Secure Shell (SSH) – Transport layer
protocol, User authentication protocol,  and port 443 rather than 80
Connection protocol.  encrypts

 Secure Electronic Transaction (SET) –  URL, document contents, form data, cookies, HTTP headers
Overview, Features, Participants, Dual
signature, Payment processing.

Connection Initiation Connection Initiation

 For HTTPS, the agent acting as the HTTP client also acts as the TLS  There are three levels of awareness of a connection in HTTPS.
client.
 At the HTTP level, an HTTP client requests a connection to an
 The client initiates a connection to the server on the appropriate HTTP server by sending a connection request to the next lowest
port and then sends the TLS ClientHello to begin the TLS layer. Typically, the next lowest layer is TCP, but it also may be
handshake. TLS/SSL. At the level of TLS, a session is established between a TLS
client and a TLS server. This session can support one or more
 When the TLS handshake has finished, the client may then initiate
connections at any time.
the first HTTP request. All HTTP data is to be sent as TLS
application data. Normal HTTP behavior, including retained  As we have seen, a TLS request to establish a connection begins
connections, should be followed. with the establishment of a TCP connection between the TCP
entity on the client side and the TCP entity on the server side
 Connection Closure Connection Closure
 An HTTP client or server can indicate the closing of a connection  A TLS implementation may, after sending a closure alert, close the
by including the following line in an HTTP record: Connection: connection without waiting for the peer to send its closure alert,
close. generating an “incomplete close”.
 This indicates that the connection will be closed after this  HTTP clients also must be able to cope with a situation in which
record is delivered. the underlying TCP connection is terminated without a prior
close_notify alert and without a Connection: close indicator.
 The closure of an HTTPS connection requires that TLS close the
connection with the peer TLS entity on the remote side, which  Such a situation could be due to a programming error on the
will involve closing the underlying TCP connection. server or a communication error that causes the TCP connection to
drop.
 At the TLS level, the proper way to close a connection is for
each side to use the TLS alert protocol to send a close_notify  However, the unannounced TCP closure could be evidence of some
alert. sort of attack. So the HTTPS client should issue some sort of
security warning when this occurs
 TLS implementations must initiate an exchange of closure alerts
before closing a connection

SSH Protocol Stack

Secure Shell (SSH) SSH is organized as three protocols that typically run on top of TCP

 Secure Shell (SSH) is a protocol for secure network communications designed

to be relatively simple and inexpensive to implement.
 The initial version, SSH1 was focused on providing a secure remote logon
facility to replace TELNET and other remote logon schemes that provided no
security.
 SSH also provides a more general client/server capability and can be used
for such network functions as file transfer and email.
 A new version, SSH2, fixes a number of security flaws in the original scheme.
 SSH client and server applications are widely available for most operating
systems.
 It has become the method of choice for remote login and X tunneling and is
rapidly becoming one of the most pervasive applications for encryption
technology outside of embedded systems.
 SSH Transport Layer Protocol
 ■ Transport Layer Protocol: Provides server HOST KEYS
authentication, data confidentiality, and data integrity  Server authentication occurs at the transport layer, based on the server
with forward secrecy (i.e., if a key is compromised possessing a public/private key pair.
during one session, the knowledge does not affect the  A server may have multiple host keys using multiple different asymmetric
security of earlier sessions). The transport layer may encryption algorithms.
optionally provide compression.
 Multiple hosts may share the same host key. In any case, the server host key is
 ■ User Authentication Protocol: Authenticates the user used during key exchange to authenticate the identity of the host.
to the server.  For this to be possible, the client must have a priori knowledge of the server’s
 ■ Connection Protocol: Multiplexes multiple logical public host key.
communications channels over a single, underlying SSH  RFC 4251 dictates two alternative trust models that can be used:
connection

 1. The client has a local database that associates each host

name (as typed by the user) with the corresponding public
PACKET EXCHANGE
host key. This method requires no centrally administered
infrastructure and no third-party coordination. The
downside is that the database of name-to-key associations
may become burdensome to maintain.
 2. The host name-to-key association is certified by a trusted
certification authority (CA). The client only knows the CA
root key and can verify the validity of all host keys certified
by accepted CAs. This alternative eases the maintenance
problem, since ideally, only a single CA key needs to be
securely stored on the client. On the other hand, each host
key must be appropriately certified by a central authority
before authorization is possible.
 Figure illustrates the sequence of events in the SSH
Transport Layer Protocol.
 First, the client establishes a TCP connection to the
server. This is done via the TCP protocol and is not part
of the Transport Layer Protocol.
 Once the connection is established, the client and
server exchange data, referred to as packets, in the
data field of a TCP segment.
 Each packet is in the following format
 ■ Packet length: Length of the packet in bytes, not
including the packet length and MAC fields.
 ■ Padding length: Length of the random padding field.
 ■ Payload: Useful contents of the packet. Prior to
algorithm negotiation, this field is uncompressed. If
compression is negotiated, then in subsequent packets,
this field is compressed.

 Once an encryption algorithm has been negotiated, the

entire packet (excluding the MAC field) is encrypted after
 ■ Random padding: Once an encryption algorithm has been the MAC value is calculated.
negotiated, this field is added. It contains random bytes of  The SSH Transport Layer packet exchange consists of a
padding so that the total length of the packet (excluding the sequence of steps .
MAC field) is a multiple of the cipher block size, or 8 bytes for a
 The first step, the identification string exchange, begins
stream cipher.
with the client sending a packet with an identification string
 ■ Message authentication code (MAC): If message authentication of the form:
has been negotiated, this field contains the MAC value. The MAC
 SSH-protoversion-softwareversion SP comments CR LF
value is computed over the entire packet plus a sequence
number, excluding the MAC field. The sequence number is an  where SP,CR, and LF are space character, carriage return,
implicit 32-bit packet sequence that is initialized to zero for the and line feed, respectively.
first packet and incremented for every packet. The sequence
 The server responds with its own identification string. These
number is not included in the packet sent over the TCP
strings are used in the Diffie–Hellman key exchange.
connection
 Next comes algorithm negotiation. Each side sends an
SSH_MSG_KEXINIT containing lists of supported algorithms in
the order of preference to the sender. There is one list for
each type of cryptographic algorithm. The algorithms
include key exchange, encryption, MAC algorithm, and
compression algorithm.
 For each category, the algorithm chosen is the first
algorithm on the client’s list that is also supported by
the server.
SSH User Authentication Protocol
 The next step is key exchange. The specification allows
for alternative methods of key exchange, but at  The User Authentication Protocol provides the means by which the client
present, only two versions of Diffie–Hellman key is authenticated to the server.
exchange are specified.  MESSAGE TYPES AND FORMATS: Three types of messages are always used
 The end of key exchange is signaled by the exchange of in the User Authentication Protocol.
SSH_MSG_NEWKEYS packets. At this point, both sides  SSH_MSG_USERAUTH_REQUEST-Authentication request from the client
may start using the keys generated from K.
 SSH_MSG_USERAUTH_FAILURE –Server rejects the authentication request
 The final step is service request. The client sends an  SSH_MSG_USERAUTH_SUCCESS—Server Accepts authentication
SSH_MSG_SERVICE_ REQUEST packet to request either
the User Authentication or the Connection Protocol.
Subsequent to this, all data is exchanged as the payload
of an SSH Transport Layer packet, protected by
encryption and MAC.

SSH User Authentication Protocol SSH User Authentication Protocol

 MESSAGE EXCHANGE: The message exchange involves the following steps.  AUTHENTICATION METHODS The server may require one or more of the
following authentication methods.
 1. The client sends a SSH_MSG_USERAUTH_REQUEST with a requested method
of none. ■ publickey: The details of this method depend on the public-key algorithm
chosen. In essence, the client sends a message to the server that contains the
 2. The server checks to determine if the user name is valid. If not, the server
client’s public key, with the message signed by the client’s private key. When the
returns SSH_MSG_USERAUTH_FAILURE with the partial success value of false. If
server receives this message, it checks whether the supplied key is acceptable for
the user name is valid, the server proceeds to step 3.
authentication and, if so, it checks whether the signature is correct.
 3. The server returns SSH_MSG_USERAUTH_SUCCESS with a list of one or more
■ password: The client sends a message containing a plaintext password, which is
authentication methods to be used.
protected by encryption by the Transport Layer Protocol.
 4. The client selects one of the acceptable authentication methods and sends a
■ hostbased: Authentication is performed on the client’s host rather than the
SSH_MSG_USERAUTH_REQUEST with that method name and the required
client itself. Thus, a host that supports multiple clients would provide
method-specific fields. At this point, there may be a sequence of exchanges to
authentication for all its clients. This method works by having the client send a
perform the method.
signature created with the private key of the client host. Thus, rather than
 5. If the authentication succeeds and more authentication methods are directly verifying the user’s identity, the SSH server verifies the identity of the
required, the server proceeds to step 3, using a partial success value of true. If client host—and then believes the host when it says the user has already
the authentication fails, the server proceeds to step 3, using a partial success authenticated on the client side
value of false.
 6. When all required authentication methods succeed, the server sends a
SSH_MSG_USERAUTH_SUCCESS message, and the Authentication Protocol is
over.
SSH Connection Protocol SSH
 The SSH Connection Protocol runs on top of the SSH Transport Layer
Connection
Protocol and assumes that a secure authentication connection is in use. Protocol
That secure authentication connection, referred to as a tunnel, is used by
Exchange

the Connection Protocol to multiplex a number of logical channels.
 SSH communications use separate channels.
 CHANNEL MECHANISM When either side wishes to open a new
channel, it allocates a local number
 All types of communication using SSH, such as a terminal session, are for the channel and then sends a
supported using separate channels. Either side may open a channel. For message.
each channel, each side associates a unique channel number, which need
Once a channel is open, data transfer
not be the same on both ends. Channels are flow controlled using a is performed using a SSH_MSG_
window mechanism. No data may be sent to a channel until a message is CHANNEL_DATA message, which
received to indicate that window space is available includes the recipient channel number
and a block of data.
 The life of a channel progresses through three stages:
When either side wishes to close a
 opening a channel, data transfer, closing a channel channel, it sends a
SSH_MSG_CHANNEL_ CLOSE message,
which includes the recipient channel
number.

Port Forwarding
Channel Types
 Four channel types are recognized in the SSH Connection  One of the most useful features of SSH is port forwarding. In essence, port
forwarding provides the ability to convert any insecure TCP connection into a
Protocol specification.
secure SSH connection. This is also referred to as SSH tunneling.
 session: The remote execution of a program. The program may  SSH Transport Layer Protocol establishes a TCP connection between SSH client
be a shell, an application such as file transfer or email, a & server
system command, or some built-in subsystem. Once a session
 client traffic redirected to local SSH, travels via tunnel, then remote SSH
channel is opened, subsequent requests are used to start the
delivers to server
remote program.
 supports two types of port forwarding
 x11: This refers to the X Window System, a computer software
system and network protocol that provides a graphical user  local forwarding – hijacks selected traffic
interface (GUI) for networked computers.  remote forwarding – client acts for server
 forwarded-tcpip: This is remote port forwarding.
 direct-tcpip: This is local port forwarding.