CPS Summer Camp at Vanderbilt University
Hey everyone. Yes, it hasn't been a year and I'm positing a new travel set. I'm on another SoS trip right now. I'm in Nashville. The Vanderbilt Lablet is holding a summer camp in CPS security. I'm here for the 2nd offering of this camp.
I have a couple of goals for being here. The first is to get familiar with the material. My objective is to be able to use the curriculum developed for the camp in other SoS outreach activities. I want to be able to have real content and demonstrations in cybersecurity. Example, have a seminar at ISEF or have a short demo in an exhibition hall. While I'm here, I can inspire and become more informed on what is going on. NSA.gov article in the future. I think so.
Now, what is this camp. This week long camp brings middle and high school students in the Nashville area (its a day camp after all). It doesn't just expose them to programming, but in the context of learning to program CPS (Cyber Physical Systems, IoT or Internet of Things) and deal with security. Its not just programming in the software side, they will be programming these robots then attacking and defending them.
Onto Day 1
Today was introduction to programing and especially the programming platform of Netsblox. This is a graphical programming environment. I'm really impressed with how much it can do without the students learning syntax. Its really intuitive and powerful. It was all web based and as far as I could tell, the students with their own computers had no configuration challenges. I do see how much underlying work must be done to make this work.
The programming tasks are really carefully done. They build and teach important concepts.
The first was a game. Put a sprite on the screen and then move it and cause conditions to happen. It was an introduction to the organization. And it taught programming concepts like if statements, variables and controls. I made a change where the player is a butterfly and there is a cat who is trying to catch you.
the second was was about drawing on the screen. At first I was thinking this logo. There is pen up and down and moving the sprite around. The key lesson here was learning the netsblox version of functions.
Now from doing shapes, we built a weather app. At this point, the kids are making programs that would take me forever to do in C. They built a weather app. They pulled map data from google, processed into and made more queries. I guess the point of this was to teach using apis.
The final part of the day was lists. Make a list, get user input, store values. The ideas of the previous section were coming together. Each project built nicely and by the end of the day the students had a good idea of how to program.
I too have a good idea of how to use this. I did the programming tasks along with the students. Sure, I might have CS degrees but today was learning the new language. It's great for teaching and makes programming very accessible.
That's it for day 1. I'll be ready for day 2 tomorrow.
Well, I manage to loose my entry for day 3 once. Let's see how my 2nd submission on today's overview goes.
To refresh, day 1, learning fundamentals of programming. day 2, controlling the robot. Now day 3, introduction to cybersecurity. The first part was recognizing that if an attacker had the code for the robot, the attacker could send any commands. The question was, if we could detect when we were under attack. The key is that the robot acknowledge each command received. This means that by listening to these commands one can develop an algorithm to identify attacks. There are multiple solutions. the computers only allowed one computer to be listening to the robot. this posed a challenge because it was hard to make the correct computer hear the acknowledgements.
The next project was do a tug a war. Not between 2 robots, but two users on one robot. The winner was the one that directed the robot to their end of the court. At this point, it was really an effort to develop code that issued the most commands. Lots of infinite loops. yet, there were multiple ways to develop control. It was really who issued the most commands won.
Part 3 was some defenses. We learned 2 defenses. rate limiting for the robot, and rate limiting with an ignore timeout per client. The later was the easier one to use and the one we did. Now we added a rate limiter and then had to adjust our attacks so that we could still win. The rate limiter would knock out the the infinite loop users.
There was also a seminar on vehicle security.
Ok, time for day 4.
Yes, It's been a while, lots of work caught up with me. I am finishing up these set of posts.
Thursday. security is in full swing. After examining brute-force attack and defenses yesterday. Today crypto was added. Sure, the actual crypto algorithms were basic, variations on the Caesar cipher, but that wasn't the point. The point is to was to make other users know a key. How was crypto used. Well. a user send a command, set key ....., and then the robot switches to using that key. This built up to the point, where all these robots would not respond to commands without that key. But that really wasn't enough. You see, that key is transmitted the first time in the clear thus an adversary could eavesdrop that message and then know what the key was.
My new partner, we switch partners this morning, wanted to use random keys. Instead of setting the key and forgetting it. he put the key in and then we developed a key switch program and put that in a loop that would change the key every 10 seconds. This routing was coded that it put a random number in there each time.
Later in the day we upped the crypto algorithm. Instead of just using one value to step all the letters, it was a set.
I decided to make an attempt at brute forcing the answer. I was successful, if not fast. I created a routine that would issue commands for each key possibility. Eventually it would find that right one. So this was slower than I expected. There is definitely a limiting factor in the number of commands to be issued. But we were patient and eventually it did work. :)
Let's return to the issue of the keys being transmitted in the clear. Let's think about this, how to deal with this year. The solution was for the robot to have the ability to blink out an initial key to use. It had 2 leds, one for 0 and one for 1. It would blink out an initial setting. Start with that and you are good to go. Only way to overhear this was to over see the key being blinked out. We wrote a program request the binary sequence and then convert it into decimal for the key usage.
That was pretty much our day.
Last day, Friday.
One more cyber attack and defense. So the avoid reader might have noticed that each command was the same when encrypted so this was opened to a replay attack. An attacker would just need to overhear a command, see what happens, and then play it back to attack and the robot would respond. This allowed the introduction of sequence numbers. Once setup, the robot will respond to any high incremented command, upto 100. Thus replay attacks no longer work. I wonder how how it would be to brute force the first digits, but I didn't try it out.
During lunch, I gave an introduction of what the NSA is and what we do and what I do. I did a little on our student programs. After lunch, switched jobs, and went and did the teleconference for the paper competition. Yep, totally different task. The students had their families come and see what they did.
I returned and talked with some parents.
And that was the camp. Hope you enjoyed reading it.
Again, if you want to get into the software, www.netsblox.org
Adam
Tuesday Day 2.
There was an odd number of students and the students worked in pairs with the robots. I volunteered to be the extra student. Today was mostly about learning to interact with the robots.
First was instruction on how to issue command to the robots. Here comes the great part. The robots are connected over wifi to the netsblox server. This means it has real-time programming. Issue a command and it happens.This enables far more interactive control.
Project 1. Develop a control functions. Map keys, like the arrows to direction. As always with programming, syntax matters. We found stray spaces can deride the thing. The other fun part of this programming is that many of the variables are globals. I know, my internal CS side, screams, but it really does make things easy. I'm not sure how the threading works.
With these skills, we prepared and race. Each took a turn around an obstacle course. There was a 10 second penalty for hitting each object. I had noticed that many times people lost time avoiding an object they already hit. I decided if I hit something, I would just plow on. Yes, it turned out that I had many strikes, 20+, but number of objects hit, a very respectable 5.No, that doesn't mean I was fast, I was terrible. the worse.
After lunch, project 1. We learned how messages are shared from the robot back. This way we could get data from the sensors. The robots have these whiskers that can tell you if they are hitting something. Wrote code to detect that input and stop. Our whiskers were flaky. Anyway, moving on to the next step was developing a self running code so that the robot will be able to drive a box around an obstacle. Two options, 1, time durations for the motors or 2 read the spins of the motors. 1 is easier so that was what we tackled first. We timed it out and successfully have it coming close to where it began. Now, the race is tomorrow where we do it and see how fast and close we get to the starting point. I expect all the timings to be messed up with fresh batteries.
So that's why the more accurate approach would be to measure how many times the tires spin. This gets complicated fasted and we didn't get it all implemented before the end of the day.
Tomorrow morning, 15min to redo timings and then race.
On another note, tomorrow, I start putting together results for the paper competition. Work doesn't stop while on work trips.