The Andrew File System was a bold new experiment in the CS department at CMU. The intent was to enable students across campus, to be able to walk up to any workstation on campus, and start using it. All the files stored in a central server on the local area network. Will be accessible in a safe and secure manner from that workstation. The assumption is that the network itself is untrusted. In this lesson we will use, the Andrews system as a case study to see how Private key cryptographic infrastructure can be used for the security and authentication of such a system. The focus in this lesson is a distributed file system being made available to a user community. And the year is circa 1988, and the state of the computing at that time looked as follows. Local area network and client workstations connecting the servers and the local disk on the workstation serve as efficient caches of files that maybe downloaded from the server.
The stage set for the Andrew File System, AFS, is the CMU campus. And the user community can access file servers using workstations connected to a local area network. And as I mentioned, local disks on the workstation served as efficient caches. And the vision of the designers of the Andrew File System and the Coda file system, both of which were built at CMU for enabling the student community to access a central file system, is as follows. A user walks up to any workstation and, and logs into the work station. And your content magically appears on this workstation from the central server as soon as you log in. In other words, in the CMU experiment, what they wanted to afford the users to be able to do is have this ability to walk up to any workstation spread out throughout the campus and be able to access their personal information that is stored in servers that are central to the entire campus. Isn't that what today's cloud computing and mobile devices are trying to do to your content? In some sense you'll see that many of the technologies that we take for granted today had their modest beginnings in experiments such as the Andrew File System and the Coda file system at CMU.
The architecture of the Andrew System looks like this. There are client workstations, which are called virtues. And these client workstations, are connected by insecure network links, to a local area network. And through the local area network, they can access servers, S1, S2, S3 and so on. And these servers are in a secure environment or in other words, accessing the servers from a client work station uses insecure links but once inside the boundary of the servers, the servers can talk to one another, exchange information, grab data from the disks and so on. This communication that happens inside this server environment is a secure communication. That's part of the reason they've named the server environment as Vice, and, the client environment, where you're accessing information from the secure servers, as the Virtue workstation. And the important thing to note is the fact that the clients have to access information from the server over insecure links. What that means is that in order to make sure that information that is sent on the wire to the servers or received from the servers to the clients. They have to be encrypted, since anyone can sniff the packets that are flowing on these wires. But inside the vice, the communication that happens among the servers, because it is secure, there is no need for information encryption. The client workstations run some flavor of Unix operating system. So inside each client workstation, there is a special process called Venus. And this process, which runs on the virtue workstation, is for the purpose of authentication of the user, and for client caching of files that the user may fetch from device servers into the workstation that they're logging in to. The user will use RPC in order to get the files that they want to work on, on the workstation. And this is where Venus comes in. Venus is the one that authenticates a user walking up to a virtue workstation, to the server and then acting as the surrogate for the user, in fetching the files that he or she wants to work on from the file server using RPC. And since I mentioned that the link that is used to communicate between virtue and vice is insecure. The RPC has to be a secure RPC. In other words, the RPC messages, both passing the parameters and receiving the results, is going to use encryption on the data that is being sent and received between the virtue and the vice file server.
Let me give you a very quick refresher on encryption. There are two families of encryption systems. One is the private key cryptosystem. And in the private key cryptosystem both the sender and the receiver sse symmetric keys for encryption of the data and decryption of the data. A common private key system that we all are using probably on an every day basis is passwords. When we log into either a corporate network or a university network. We use a username and password and that is using a private key encryption systems. The idea is simple. The sender takes the data that they want to send a receiver and encrypts the data using a key and this key is a private key that is known only to the sender and the receiver space and nobody else. So by encrypting the data with this key they produce what is called a cyphertext and the cyphertext can go on insecure links. Anybody can see the bit pattern of the cyphertext, but in order to make sense out of the cyphertext they have to decrypt it. And to decrypt it they need the key and the key is only available between the sender and the receiver. So this is where Salsa's principle comes into play. That is, publish the design, but protect the key. The keys are protected between the sender and the receiver. You're publishing the method by which you are transfering information between sender and receiver. Namely, using a private key encryption system. But, for any bad guy to access information that is flowing on the wire they have to have the key in order to make sense out of the data that is flowing. And you make breaking the key hard enough, computationally, that the system is secure. Now one of the problems with the private key system is the fact that the keys have to be distributed to the sender and the receiver and key distribution problem is one of the difficulties with private key cryptosystems. Especially as the size of the organization becomes larger and larger. The public key cryptosystem overcomes this key distribution problem. And in this case there is a public key which is published. The name itself suggests the idea behind the public key cryptosystem. And that is, anyone can create an encrypted data by taking this public key, which is available, let's say published in the Yellow Pages. They can take the public key, take the data that they want to send and encrypt it, and send it on the wire. But in order to decrypt the data. The public key is no good. You need a private key that is the only way to decrypt this data. Well, in other words, the mathematical underpinning of the public key cryptosystem is that there are asymmetric keys, a pair of keys for information exchange. In order to encrypt you use a key that is a public key. Anybody can have access to that. But in order to decrypt that, you need a private key. And, conversion of data into a cyphertext using the public key is a one-way function, which is not reversible. Similarly, converting the encrypted message into the original data using the private key is another one-way function. So one-way functions are the mathematical basis for the public key cryptosystem. So now, the way you would send data, if you're the sender, take the data, encrypt it using the public key. You create a cyphertext. Once you have the cyphertext, you cannot convert it back to the data using the public key. The only entity that can convert the cyphertext back to its original data is the entity that has the private key. The other part of this asymmetric key infrastructure, namely, the private key and using the private key, you can decrypt the cyphertext and create the original data. So this is the workflow for a sender to encrypt the data, clear the cypher text, send it to the receiver, receiver decrypts it using the private key, and produces the original data.
So here is a private key crypto system in action. Two entities, A and B, have exchanged keys. A will use the key KA to send a message to B, and B can decrypt the message using the same key KA. And similarly, when B wants to send a message to A it encrypts it lets say using another private key key B and when the message comes over here A will decrypt the message using the same key that was used for encryption namely key B. So one of the things that should be obvious is that, in order for this private key encryption system to work, both the entities need to know when they get an encrypted message who is the author of the message, because that is the only way they know what key to use in order to decrypt this message. So if a sends a message to b,it's sending this encrypted message. When this cyphertext arrives here, for B to know that it has to use this key KA, it needs to know the identity of the sender. So the identity of the sender has to be sent in cleartext. So this is the format of a message that is going from A to B. The identity of the sender in cleartext Meaning that, looking at this, we will immediately know, this message is from sender A, and therefore, I should use key k A to decrypt the cyphertext, and vice versa when A gets a message from B. Of course, k A and k B can be the same, or in other words, it is the same key that is used for, A to send a message to B as well as for B to send a message to A. But the important thing to take away is that the key that is used for encryption and decryption of a given message is exactly the same, that's the idea behind the private key encryption system.
There a few key challenges in implementing this Andrew system, which is intended for campus environment. User community consisting of students, who can login to work stations anywhere on campus and those workstation are connected by insecure network links to central server. And a simple server is a depository for all the files of the entire user community. So the challenges include authenticating a user. That is, when a user says I'm Kishore, the system has to verify unambiguously, that the user indeed is Kishore. A second challenge is authenticating the server. That is, if I, as a user, log into a work station and I get a message from the server, I have to be assured that this message is actually coming from the server. And not some Trojan horse that is pretending to be the server. The third challenge is preventing replay attacks. And what that means, is that even though we using encryption to secure the data that is going on the wire, someone that is sniffing the wire Could grab a packet and then resend that same packet, and that should not fool either the sender or the receiver. That's what is meant by replay attack, and the [UNKNOWN] challenge is of course ensuring that the user community is shielded from one another. Either due to unintended interference of user or another, or malicious interference. Both of those situations have to be avoided. So that is what I meant by isolating users. So these are the design challenges for the Andrew system. So in the Andrew file system, they decided in order to make sure that all of these challenges are met, they have to use a secure rpc as the basis for client server communication. And, in implementing the secure rpc, they also decided to use private key cryptosystem, and I mentioned. That the public key crypto system does not have the key distribution problem, but on the other hand, for a closed community like a campus environment, the key distribution problem is not as big a challenge, so therefore, the design of the Andrew file system decided to use private key crypto system. And as I mentioned earlier in the private key crypto key system in order to identify what key to use to decrypt a message that is coming in, the identity of the sender has to be known. So this has to be sent in clear text. If you take a traditional operating system like Unix you have username and password which is the way you authenticate yourself for the system. But, in a campus environment if you're going to use, Secure RPC as a mechanism for communication between the client and the server. There can be lots of communication that is happening between individual clients and the servers. And if you're going to use, use a name and password all the time for such communication. Such overuse will result in a security hold. One of the things that I mentioned, as a principle proposed by Jerome Salser is you publish the design but protect the keys, but you publish the design but protect the keys. And what is meant by protecting the keys is making it competitionally hard to break the key but over exposing the key. Allows someone to take a long time to crack the key, and therefore overusing username and password as the basis for all communications, in a circular RPC, will pose a security hole. So the dilemma that the Andrew Fine system designers had to face, was what to use as the identity. That needs to be sent in cleartext, and what to use as the private key so that we don't always use any pair of identity and private keys for a long time.
The solution that they took in Andrew is as follows. Only for logging into a workstation the user name and password are used. And of course, they have to be securely communicated to the server Over insecure links, we'll see how that is done. But the key point is that username and password is only useful logging in. Once a user is logged into a workstation, at that point onwards for the rest of the log-in session, the intent is to use ephemeral IDs and ephemeral keys But all the subsequent Venus to vize communication. Recall that Venus is the process that resides on the virtual workstation, acting as a surrogate for the user for file caching. And vize is, of course, the server that is living inside A secure environment. And this venus-vize communication happens over insecure links, that's where we going to use ephemeral ids and keys. So this gives rise to three classes of client-server interactions. The first interaction is logging in, imagine you're a student, and you're doing a course project. What is that you're going to do. You're going to walk up to a work station and log in presenting your username and password to the workstation. And this username and password is going to be used as the basis for, the client server communication that lets you authenticate yourself to the server. Now once you authenticate yourself to the server what are you going to do, well you want to do a cost project, and for the cost project you probably need to download some files to the server. And that requires that Venus that is running on your workstation establish an RPC session with the server in order to fetch the files that you need to work on for your course project. That's the second class of client-server communication, establishing an RPC session. Now once you establish an RPC session, then you can request the files that you want as a user. As a student you want certain files to be accessed during this RPC session. You bring those files and once you brought in the file that you want, you can close the RPC session, work on your project locally on the workstation. And once you're done with completing whatever work you needed to do, you may establish a new RPC session to upload the results,of your work back into the file server. So the three classes of client-server interactions are logging in, which happens exactly once for the entire loin session, and RPC session establishment, which may happen several times during the time that you're logged into work station. Every time you decide oh, I want to fetch a new file. Oh, I want to store this file back into the server. The third set of interaction is the actual file system access during the session. Once this RPC session has been established by venus with vize, then you as the user, you may want to work on a particular file You may open a file. At that point, Venus will go, using this RPC session, and fetch the required file and cache it locally for you to use it, and later on, if you close the file, at that point, Venus will commit the changes that you made to the file to the central file server again. So that's the kind of file system operation that's the third class of client server interaction. And for both RPC session establishment, and for the actual access to the file system during an RPC session, we want to use ephemeral ID's and keys.
Let's first understand how the login process works? You walk up to a workstation and you login. And how do you login? Well you login using your username and password and this login process is special that runs on the virtue workstation. It, communicates with the login server that is inside the vice by presenting the username and password in a secure fashion. We'll see how that is done in a bit. So it presents the username and password securely over the insecure links. To the login server, and the login server, once it authenticates who you are, using the username and password, it is going to send you a pair of tokens, and remember all of this is happening on behalf of the user by This merge in the virtual workstation. The user has to do nothing special. All that the user is doing is logging in using a user name and password. Under the covers these things are happening. First, the log in process communicates securely with the log in server presenting the user name and password. And the login server then returns two tokens. One is called a secret token. The other is called a clear token. The clear token, is a data structure. Once again I have to mention that both the secret and clear tokens are communicated back To the log in process, by the log in server, in a secure manner over the insecure link. We'll see how that is done in a minute. So once, the log in process gets these two tokens, decrypts them and gets these two tokens, the log in process decrypts the message that contains these two tokens. And extracts the clear token and the secret token. The clear token is really a data structure which is known to the login process. And the data structure in particular contains a handshake key. We'll call it HKC. So from this clear token data structure, the login process can extract this handshake key And the secret token is just a bit string. So far as the login process is concerned. The weight is generated by the login server, is to encrypt this clear token. With a key known only to vice. It's not the same as HKC. It is a key that is known only to vice, to encrypt the clear token. And we will see how this key is going to be used, later on. So to recap, virtue sends securely the username and password to the login server. Login server securely sends secret token and clear token back to this login process. From the clear token The login process extracts the handshake key. And the secret token is basically a bitstream, which is an encryption of the contents of this cleared token, encrypted with a key that is known only to Vice. In other words, the secrettoken is unique for this login session, and It is a bit string, which means nothing to anybody that sees it on the wire. And therefore we can use this bit string that secrettoken represents as ephemeral client-id for this login session. Recall I said. We don't want to expose the user name and password Too often on the wire. This is Andrew's answer to dealing with a problem, by providing an ephemeral client ID for this login session. Once I use it as logged in, they get an ephemeral client ID, which is the secret token. And this can be used in the future communication between virtual And vice as the client ID. Now, how will vice know who is communicating with it when it sees this bit pattern? Remember that this bit pattern secret token is an an encryption of the clear token. And the key for decrypting it is know only to vice. So when the secret token comes as the client ID, vice can decrypt it and find out from that, what is the clear token associated with that particular bit stream which is representing the secret token. And once it knows that, it can also extract the handshake key that it gave to particular client, and that's how the identity of the client that is communicating with the vice in the future, presenting this secret token as the ephemeral client ID can be recognized by vice. So now, after the login is done, for all the future communication between Venus and Vice, HKC can be used as a private key for establishing a new RPC session. This pair of tokens, the secret token and clear token, is stored on the Virtue workstation by Venus. On behalf of this user for the entire login session. At the end of this login session, these two tokens will be thrown away by Venus. But during the login session, these two tokens are representing this particular that has logged in. And, so for the duration of this login session. Venus will use the secret token, which is a bit string that represents this particular user for this log in session, as the client ID to send information over to the vice. And, any information that Venus sends to vice to establish an RPC session is going to be. Encoded, with the private key that it had been handed now through the clear token data structure. That is the handshake key that had been given as part of this log in exchange, through the clear token data structure. At the core of the entire secure RPC system of. The Andrew file system is the bind mechanism, for setting up a client server connection securely, and that's what we're going to look at next.
Now that the user had logged in to a client work station, Venus will establish an RPC session, on behalf of the client. And in order to establish the RPC session, the following message exchange is going to happen. And this is what is called the bind operation between the client and the server. So what Venus is going to do is send the client identity and an encrypted cipher. The client identity, as I mentioned earlier, in private keycryptal systems, you have to send it in clear text so that the server knows the identity of the client and in order to establish a new RPC session, Venus will use the secret token as the client identity. And it will use the HKC, the handshake key for the client that was contained in the clear token data structure that was given back to the work station by the server as part of executing the log in process. That is the key that will be used for encrypting the starting message for the RPC session establishment. Now what exactly is the massage that is being sent. Well all there is sent for initiating this RPC session establishment, is a random number which is new for each RPC session that Venus is establishing on behalf of this client. Every time it wants to establish a new RPC session within a login session, it creates a new random number and encrypts it using the handshake key. That's the cipher text. And the secret token is the client ID, and that's the message that goes from virtue to vice, the server. So when this message arrives at the server, how will the server decrypt this message? Well, the client ID is the secret token. Recall that the secret token is nothing but an encryption of the clear token, with a key that is known only to the server, and therefore, what the server can do is take the secret token, decrypt it using the key that it has and once it decrypts it, it gets this clear token data structure and from the clear token data structure, it can say well what is the key that is contained in this clear token data structure, take the key and decrypt this message. Cause, that key is HKC, and that is how the server can get the message that has been sent as the initiation of the RPC session. So in particular, what the server has gotten now is the random number that was sent to it by Venus Xr. Now what the server does, is it takes this random number, increments it by 1, and also adds a new random number, Yr, and that is a message that it is going to send back to the client. It has to encrypt this message of course, because its going on the wire, which is insecure. So it's going to encrypt it using a key, a handshake key which we'll call HKS and by design, HKC and HKS are exactly the same. So in other words, whatever is the handshake key that has been given to the client in the clear token, is the same handshake key that the server is going to use to communicate information back to the client as well. So, it encrypts this message with this handshake key and sends it over to the client. So what is the purpose of this message? When this message comes over to the client, the client can decrypt this message. How? It's going to use HKC which is the handshake key that it knows will be used by a genuine server to encode the message and send it to the client, and so it can use HKC to decrypt this message and once it decrypts this message, it gets these two numbers. There's Xr plus 1, that is the original random number that this guy sent over to the server incremented by 1. Now what is the purpose served by this number, Xr plus 1. It actually establishes to the client that the server is genuine. Anybody could replay a message that they see on the wire, but for this message to have the right content, what the client is expecting is that the response that the client is going to get for the original message that was initiating the RPC session. is that the response from the server is going to contain a number that is 1 greater than the random number that it sent the server in the first place. So, if this number, Xr plus 1, is what the client was expecting, then it establishes that the server is genuine. So this goes back to what I said about authentication of the server. That is one of the challenges that the [INAUDIBLE] system has. This is the way the virtue workstation, the Venus process on the virtue workstation on behalf of the client can establish the genuineness of the server that this workstation is talking to. Or in other words, it's not a Trojan Horse that is sending this message. But it is genuine server that is sending this message because this field is exactly what Venus expected it to be. Now what is this number? This is another random number that the server is sending as part of this message. Why is it sending this random number? It'll become clear in the next set of communication that's going on between Venus and Vice. Now once Venus has extracted this Yr from this message, what it is going to do is it is going to increment it by 1 and take that as a message, Yr plus 1, as a message, encrypt it using the handshake key, and send it over to this server. And when the server decrypts this message and extracts this field, it'll see whether this field is what it is expecting it to be. What the server is expecting is that this will be Yr plus 1. And if the client is genuine, then the client would've been able to extract Yr from this response that came from the server and generate Yr plus 1 and send it over to the server. So in other words, this message coming to the server is establishing the genuineness of the client, because this original message that we saw could have been just a replay, meaning somebody sniffed the network, got a hold of this packet, and replayed it. But if they replayed it, then they would not have the key, and they would not have been able to decrypt this message. So the fact that the client was able to decrypt this message, extract Yr increment it and send a new message that contains Yr plus 1 to the server is authenticating to the server that the client is genuine. Just as this message established to the client that the server is genuine, similarly, this message coming from the client to the server is establishing to the server that the client is genuine. And this pair of communication that you are seeing is also avoiding replay attack either from the client to the server or from the server to the client. In both directions, we're avoiding it by this trick of generating a new random number. For establishing an RPC session and communicating it back and forth between the client and server.
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.
In the Andrew file system, the sequence, client sending a newly generated, random number, and the server responding with an increment of that random number back to the client. This exchange establishes one of two things. Either that the server is genuine or the client is genuine. The second question is the sequence, the server sending a newly-generated random number, Yr, and the client responding by taking the random number, incrementing it by 1, and giving it back to the server That establishes, that the server is genuine, or the client is genuine.
This sequence establishes that the server is genuine, and this sequence establishes that the client is genuine.
It turns out that login is a special case of the general bind operation that I described to you, and it is a special case in the following sense. Password that the user has for logging into the system at any point of time is used as the handshake key to start with. And username is used as a client ID. So, to initiate the login session, the login process, the username given to the user as the client ID, and the password as the HKC. But other than that, it follows the same sequence of validating itself to the server, and, similarly, validating the server to the client. And at the end of that validation of both the client and the server, what the server gives back to the login process, as I mentioned earlier, are a pair of tokens. The secret token, and the clear token. And these two tokens have to be sent securely on the wire, which is insecure. So what the server will do is encrypt these two using password as the handshake key. And therefore, the login process can use the password to decrypt the message that comes back from the login server, and get these two tokens, secret token and clear token. And these two tokens are kept by Venus for the rest of this login session. And as we know, once we've gotten these two tokens because clear token is a data structure that contains the handshake key needed by Venus for establishing RPC session, the rest of the life is made for us.
Let's put it all together and see how Android file system enables authorized users who are members of a campus community to log in remotely from work station over insecure links and use private key crypto system to validate the users. And allow them to get useful work done on the work station. They login using the username and password. They get back a pair of tokens a secret token and clear token, and this is the first communication that happens between venus and vize. Venus can then establish an RPC session on behalf of the client by using the secret token and HKC. That's the second class of communication that happens between Venus and Vice, and as a result of this session establishment. What Venus gets back is a session key for use in this particular RPC session. Subsequently, any time the user opens a file, or closes a file, or writes to a file, all those file system calls. That requires Venus to communicate with vice, is going to be sent as secure RPC using the secret token as a client ID and SK, the session key, as the private key for encrypting the message that it wants to send. To vice, and similarly vice is going to send back responses uses the session key. So this is a third class of client server interaction that I mentioned. So there are three classes of client server interaction. The first one is login, second one is RPC session establishment, and the third one is the actual. Secure RPC calls that are being made for manipulating the files sytem that resides in the central server. So the upshot of this structure that Andrew Files System provides for the user community is that the user name and password is exposed only once per login session. So in other words if a student logs in to a work station once or twice a day, it's only that many number of times that the user name and passwords are going to be used on this insecure network. The hand shake key that Venus gets back as a result of setting up a login session for a user is used only for new RPC sessions. That's a second class of communication. And the validity of this hand shake key is the duration of the login session. You know that passwords have a long ability deed as valid as long as you don't change your password but, the duration of this HKC that is used for RPC session establishment, that is only for the duration of the login session. Once the user has logged off and left this work station. A secret token and a clear token are thrown away by Venus, so the duration of the HKC is only for this login session. And a session key is used for all the RPC calls that Venus is making on behalf of this client from manipulating the file system. And the duration of SK is the duration of a given RPC session. For instance, within one log in session, let's say, I have three different RPC sessions. For each of those distinct RPC sessions, I'm going to get a unique session key. And I'm going to use that session key only for that particular RPC session. Once that is done, I cannot re-use that key anymore. I'll have to re-establish a new RPC session, and get a new session key, and restart the RPC session. So in this lesson, module as a whole. First, we looked at taxonomies proposed by Solser, and then, we saw how we can build a practical system, which can be used by a campus community for securely accessing information. In this case. Files stored in a central repository through the Andrew file system. Now, it is time for a question that is really asking you to think about the Andrew file system and its strengths and weaknesses with respect to providing security guarantees for the user community.
So I want you to fill out this report card, which says, how well is AFS doing as a secure system. And I want you to think about some of the challenges that a secure system has to face. The first one is mutual suspicion. Meaning can I trust the server. Can the server trust the client? Can I trust my fellow users in the community? Is that challenge addressed by AFS? I want you to give a binary answer, yes or no. The second attribute I want you to evaluate the Andrew file system on is whether the users are protected from the system, or in other words, can the system do something bad to the users? So that's the second attribute I want you to evaluate. Once again, a binary answer, yes or no. And the third attribute is confinement of resource usage. In other words, does the system ensure that no particular user can overuse resources available in the system. The resources could be network bandwidth and so on. Again, binary answer. The fourth thing that I want you to evaluate the AFS system is on authentication. Whether it provides authentication in both ways. Both authenticating the server to the client and the client to the server. The last attribute is the integrity of the server itself, meaning can the server be compromised in any fashion. That is the last attribute I want you to evaluate. Once again binary answer, yes or no.
AFS passes the first test. It does address the issue of mutual suspicion from fellow users, as well as from the server. Unfortunately, AFS fails the second test and that is protecting the user from the system. There's no way to protect the user from the system because the user has to trust the system. Everything is stored on the system, so in that sense there is no protection for the user from the system itself. It also fails on the third attribute, confinement of resource usage. For instance, a given user can make a lot of calls on the server. In other words, they could consume a lot of network bandwidth. There's no way to confine resource usage in the Andrew File System. And this can also be the basis for Denial Of Service attacks. If one malicious user or an errant program that is running on the virtual workstation starts generating a whole bunch of network packets, genuine network packets, directed at the server, it can inundate the network and prevent others from getting useful work done. So, in other words, confinement of resource usage is not something that exists in the AFS system. It passes the authentication test. We can validate in both directions, the client and the server, so the answer is yes on that one. The last attribute is the integrity of the server, remember that in the Andrew system the assumption is that the clients running on the virtual work station, they communicate to vice using insecure links. On the other hand, the servers themselves are inside, in some sense, a firewall and therefore they don't need any secure communication. So their links that are inside the server network is assumed to be secure and therefore there is no authentication or encryption inside the server network. Therefore, if somebody were to somehow get into that firewall they can create havoc. So the only way you can give server integrity in the Andrew File System is by physically enforcing who can get into those walls of the server. So physical and social mores are the only way to secure the integrity of the servers themselves. So I'm going to give it not a passing mark on server integrity, because by design, the servers are assumed to be in a secure environment and that can be one of the biggest sources of vulnerabilities.
And your file system has features that extend the privilege levels provided by the unique file system symantics. This includes groups and sub groups and. Accesses for files with both positive and negative rights. Negative rights is especially useful for quick revocation. Further, it also introduces the notion of audit chain for system administrators modifying the system. I urge you to read this paper in its entirety. To get a feel for the extensions proposed in the Android file system. The main takeaway, however, in this lesson is how, as operating system designers, we can take the best solution that is out there for information security and implement a secure and usable distributed system. Further, once designed and implemented, we should be able to bench mark our solution against the design principles laid out by Salser on information security, and know the vulnerabilites that exist in our solution. This last point is particularly important to safeguard our system against attackers. As we mentioned at the outset of this course module, the topic of information security is fascinating, and it is of high relevance in this information age. Hopefully this course module has spurred your interest. In information security, to seek, more, and future courses.