University of Southern California
Arp spoofing (DETER)
Tunnels and vpns (DETER)
Computer forensics (DETER)
lecture 4:30p - 5:20p Fri OHE122
Until recent years, information systems security was the limited focus of the military and the financial communities. With the recent explosive growth and merging of telecommunications and computing, security has become an integral element of any reliable and robust information systems environment. This class will cover information systems security at the graduate level. Students should have a basic understanding of networking and operating systems prior to attending the class.
Lab grades - several students have asked. I have asked the lab graders and TAs to coordinate. I expect grades will be published in a batch, upcoming, covering the first several. (10/22)
Note calendar adjustments for next week's midterm - covered in lecture and the first few lecture slides for today (on Firewalls topic). (10/10)
Lab switching from Wednesday to Friday for career fair - apparently there is a career fair scheduled on campus that coincides with Wednesday lab. A few Wednesday students contacted me requesting to switch to Friday and I individually approved. Then the number of such requests grew to, I think, more than the capacity of the room. There are not enough extra seats in the lab on Friday to accommodate all those who want to attend Friday instead of Wednesday. I suggest that any Wednesday student who wants to attend the career fair event instead of lab should do so. Then, attend lab on Friday and expect to share a computer with another student. It might be a little crowded or uncomfortable. But for our purposes I think two students can both gain the desired experience while sharing a PC. If this works OK then great, go home and write this lab up. If it proves a great catastrophe, or at least some students don't get a chance to understand the point, maybe I can set up a remote server after Friday as a partial, substitute environment and you could do the work from your own Wireshark-equipped environment. We'll cross that bridge if we come to it however. Meantime, please go to the career fair if it is important to you, and to Friday lab. Incidentally your TA Simon Woo will be substitute grader on Friday. He himself was a past CS530 lab grader, and a good one. (10/7)
DETER accounts created tonight - this should trigger auto-generated email messages to each of you, identifying your user account name and asking you to make a couple of profile changes within, I think, a 72-hour time window.. The names will be of the pattern sc530aa, sc530ab, etc. Please try to respond to the message promptly. The majority of our remaining lab exercises will be done remotely on DETER. See the links in the column at left under the heading "DETER net testbed." (10/1)
"With heartbleed, what data do I get," I was asked after class yesterday. You get whatever data is neighbor in RAM to the heartbeat payload. The payload originates from the client; the server does a write/read depositing it in memory then reading it back to boomerang it to the client. But he reads back too much. What data lies adjacent to the payload? Whatever was placed there recently, by whoever placed it. It's a multiprogramming system and we don't know. The data coming back is unpredictable and uncontrollable by the attacker. In the slide below, I used the web form just to be able to get some known-quantity thing into the server's memory. Thereafter, I ran the exploit about 10 times, scrutinizing what came back trying to spot "EAZZZ...ZY2SEE..." The first 9 times it wasn't there, the 10th time, bingo, there it is (below). A real-world web form might have solicited something sensitive, like a credit card number or credential of some kind. Web forms are, after all, how you supply your card number to an online merchant. Not just apache, as here, but any software that uses memory (which doesn't?) may place its data in heartbleed's path. So session and private keys, if any software ever used them, might show up.
Please do not conclude from this slide that I deliberately constructed what you see. I hoped for what you see. I was on a fishing expedition and got lucky, eventually. But those trophy catch photos never tell that the fisherman labored in vain since sunrise before he finally hooked the big one.
"'Come on, fish,' he said. But the fish did not come...'Fish,' he said softly, aloud, 'I'll stay with you until I am dead.'" The Old Man and the Sea, Ernest Hemingway. (9/27)
Please use the prescribed
keywords when emailing lab solutions to firstname.lastname@example.org
each week. Till now I have individurally requested re-submittal of email
messages that arrive without them. From now I will stop.
Last week's lab lecture online can be found at
The appearance of a link to it at courses.usc.edu has been delayed, but the video itself is up online. (9/22)
Yubikey authentication - we looked at it briefly in lecture last week. We didn't spend enough time on these slides about key sharing. The yubikey device on an application client produces an output intended for use in conjunction with an authentication server that can evaluate that output. (Incidentally while the server in my slides belonged to manufacturer Yubico, maintained for customer use, customers also have the option of creating their own server to avoid sharing secrets with any external organization.) The slides show that part of a yubikey's output is encrypted, and the symmetric key for that is internal to the yubikey. That key therefore must be shared with the server, and my slides show it to be in the server's possession. There are different approaches to secure key sharing. One of the questions in your lab instructions asks you to think about how it was accomplished in this case. (9/19)
for the respective labs we do over 10 weeks. Please be sure to embed these keywords in the titles of the email messages in which you will submit your work. (9/12)
New lab times published - please check and let me know of any anomalies, conflicts, problems. (9/8)
Further lab timeslot assignments - since Friday I have not yet assigned additional sign-ups. I expect to do so tomorrow, Monday, and publish a revised list at the "Student lab times" link. In the meantime, anybody not yet assigned who wishes to attend tomorrow may do so. (9/7)
Authentication without confidentiality - below is one of the slides we didn't get to yesterday. What's the stuff in the red box?
Note there is no encryption of the data, the purpose is not to obscure the data but to make certain it came from Fedora. (9/6)
Clarification - lab meeting times have been assigned, but the actual meetings don't start until next week. Those of you assigned to the Friday 3pm slot need to come next Friday but not today. Today, we have just the regular lecture in room OHE122 at 4:30pm. (9/5)
My RSA lecture available online - The latter slides in my lecture presentation today cover the steps and math of the RSA algorithm. They are closely related to the lab activity you'll do in a week. I have those slides online, with my narration. You may listen to them if you like (it would help) before coming to the lab next week. (9/5)
Labs, due dates, lab time assignments round 2 - The lab performed in a given week will be the one that was the lecture subject on the previous Friday. The due date for submitting its result will be by your particular lab time the following week. Take as an example the cryptography topic and a student in the Wednesday lab. The lecture for it is today; you'll do the lab exercise next Wednesday September 10; your electronic submittal of the result is due the following Wednesday September 17 at lab time, 10:30am. DEN students have a Friday 4:30 deadline; the remote assignments on DETER later this semester will be due Fridays at 4:30 2 weeks after lecture date.
If your name does not appear among the listed student lab times it is because you did not supply preferences or supplied them malformed. I will hold another round of time assignments for you. (You will have second priority, that is, I will not disturb or move any of the students already assigned to meet your preferences.) Please visit the web form today and express preferences. I will randomly give times to students who do not. (9/5)
The number of students of record is 68. 48 of them appear in the "Student lab times" schedule. 9 did not provide preferences. 11 supplied preferences in improper form which therefore were not processed.
preferences not provided: briggs, guptaan, guptaav, mante, maraliga jayaram, palaniappan, patwardhan, tuse, venugopal
preferences provided in improper form: wadhawan, balakrishnan, balasubramanya, narayanan, vemuri, thakur, shamanur, khatri, shiroor, poobalan, luo (9/4)
Which machine do we use, for which lab? - the various lab activities were developed to work on one or another of the 4 virtual machines installed in the lab. The instructions for each lab should tell you on which platform to do it. As a matter of record, here are the platforms corresponding the activities.
Revised lab calendar (below) - to reflect the 10/17 midterm. (8/30)
First homework tasks -
Individual lab timeslot assignments
You will be assigned to a particular lab session. You will express preference among the timeslots using this web form:
On the form (which unfortunately does not validate entries) please take care to
enter a unique explicit digit from among 0, 1, 2, and 5 for each of the
seven lab timeslot possibilities.
The software that will process your entry will filter it out if it deviates from that. So fill in the form correctly to avoid adversely affecting our meeting your preference. I will do my best to follow student preference within my ability to control. (8/29)
The web form is here . To use it, you need to supply an ID. Your ID is your last name, all lower case. On-campus students who were registered as of yesterday are in the web form's database. There are multiple guptas and multiple kims. In those cases suffix your last name with 1 or 2 characters of your first name. I will make a supplemental update with names of later registrants sometime next week as a fresh class roster is made available to me. (8/29)
Strong recommendation - each week, preview or scan (visually) the lab instructions in advance before your lab session. It will enable you to do the exercises more efficiently, with greater understanding, and ensure you can finish before the lab ends. (8/29)
Support questions - try the "Labs" category of the discussion board found on DEN/Blackboard for CS530. If it's a question of general interest (maybe somebody else has the same question in mind) put it there. Alternatively, or for more specifically personal questions, email@example.com email address, shared by me and the lab graders. (8/29)
Your graders - Serhat Yilmaz and Adhip Gupta. Adhip took CS530 last year, Serhat did so earlier and was a lab grader last year. Both are helpful and familiar with the lab exercises you will do. (8/29)
Lab location - room OHE406. The hardware-identical computers in this room have removable hard drives. You will be assigned a drive. You will insert it in one of the computers when you arrive at the lab each week. You will put it in a locker afterward, where it will be stored for you until the following week's session. (8/29)
DEN students - most if not all of the lab exercises are performed in VMware virtual machines. We will make available images of the same vm's that are installed in the lab, for you to install on your machine. You will then be able to run that vm using VMware player, which is distributed free from www.vmware.com. The lab handouts (instructions) will be posted online, here on this website, weekly. I intend to distribute the vm images to you via download, details to be posted on this website. (These are not for the consumption of on-campus students.) (8/29)