Okay, now we know that the kind is genuine, and the server is genuine. Now what?
Once again we go back to the principal of not overexposing any ID or
password for too long on insecure links.
Remember that the login session used the username
and password exactly once. Now the RPC
session, you may be establishing multiple RPC sessions.
Over the lifetime of the login session.
Once a login session has been established,
then you are establishing the RPC session.
Now within this RPC session, you may be
making a number of File system calls. And for all of those file system calls,
you don't want to over expose the use of this handshake key. And therefore
what the server does in the Android file system is. Use this handshake key
only for establishing an RPC session. Let's say within a login session, you have
three or four different RPC sessions, with the server. Three or four unique
RPC sessions. For each one of those unique RPC sessions, you have to use the
handshake key to establish the RPC session.
But, within an RPS session, what you're doing,
is you're making a whole bunch of secure
RPS calls, to the server, for opening files,
achieving new files, writing files and so on, and for all of those we don't want
to over use this hand shaky, and that's the reason, what the server does once
it validates the indentity of the client,it generates a
session key. Which is for this particular RPC session. Now it's going to
send this new session key a generated this particular RPC
session as an encrypted cipher to the client using
the hand shaped key. As the private key for encrypting
this message. And now Venus can extract
the session key using HKC to decrypt this
message and this sk is the session key for use for this
particular RPC session. For the rest of this RPC session, any time the client
wants to open a file or close a file or write a file or
read a file, all of those file system
operations is going to use session key as the
handshake key for the rest of the RPC
session with the server. The second field, num, is
the starting sequence number that Venus will use
on behalf of the client for all the
file system related RPC calls that are going
to be made as part of this particular session.
For this session, SK, is going to be the handshake key, and the sequence numbers
going to start here. There's again a safeguard against replay attacks on the
server, by someone masquerading as a
client, and generating packets with certain sequence
numbers. So let's recap. What went over
for session establishment. The first message coming
from the client to the server tells the server that
a client is wanting to establish a new RPC session. The server has
to authenticate whether that particular session establishment
request is genuine or not. And the client has to know
that it is really talking to a genuine server, and
that's this pair of communication that you're seeing here.
One to establish to the client that the server
is genuine, the second to establish to the server
that the client is genuine. And once the genuineness
of the client and the server has been established,
the server says, for this particular RPC session, we
will not use this handshake key anymore for the
rest of the communication that we want to do
for file system operations. I will generate a new session key, SK.
Give it to you along with the sequence number to use as
a starting sequence number for RPC calls during this session. That's the
whole exchange that we're seeing here. Now it's time for a quiz.