So, welcome to practical cell phone spying. Before we start, a couple of notes on privacy. First off, cellular phone calls will be recorded during the talk. Surprise. If you do not want your cell phone calls recorded, turn your phone off. If you're on Sprint or Verizon, you're not GSM. My system is not going to talk to your cell phones at all, so don't even worry about it. Having said that, I would encourage people to keep their phones on during the talk, especially if you've got a GSM handset, because the whole point of this is to show how your phone calls can be intercepted, and if you're not using your phone, then that kind of doesn't work. Okay. This is the machine that's actually running the demo. I don't know if you can see this big gap here where the hard drive should be. It's actually booted from this USB key, and at the end of the talk, I'm going to be cutting that USB key in half with a Leatherman. So, I'm recording all kinds of very, very sensitive information, all kinds of settings about your phone, logging phone calls, all this kind of stuff, but it is all going to be destroyed at the end of the talk, so don't worry about that too much. Let me just get my power back in here. Thank you. Okay. Finally, I do have backhaul in place here. I'm currently connected to my Verizon Droid, which is giving me voice over IP backhaul, so if you do connect to the network, generally the only way that you'll know that you're connected to the network is when you try and make a call. If you do make a call from the network, you'll get a recorded message saying you're being intercepted, yadda, yadda, yadda, so effectively keep your phones on during the talk, and every so often just dial a number, see what happens. If you hear that recorded message, then you're attached to my system here. If you don't hear the message, you're fine. In either case, anytime that anyone is connected to this network, a best effort is going to be made to connect calls subject to the limitations of asterisk going over voice over IP, going over Verizon, and given that Verizon is the only cell phone network that, well, one of two, we may have unpredictable results, but we'll see. Okay. So the whole idea of the talk is, I'm talking about IMZ catchers, but in order to know what an IMZ catcher is, you need to know what an IMZ is. An IMZ is an international mobile subscriber identity. You can think of it kind of like a GSM username. It's one of two parts of the two things that live in your SIM card that authenticate you. Your IMZ is like your username. KI is the secret key that authenticates you into the network. So IMZ lives on the SIM card, obviously. It's somewhat protected. When you connect to a network, one of the first things that that network does is it'll say, stop using your IMZ, use this temporary IMZ instead. And what I'm going to be showing you on the demo a little later is how many of these TIMZs have been allocated as a way of seeing how many people are associated with the base station. So an IMZ is kind of a secret. The ICC ID, the long string of numbers that's printed on your SIM card, it's fairly closely related. For most U.S. networks and a lot of networks around the world, actually, you can derive the IMZ from the ICC ID and vice versa. So it's not really that secret. Other places do it slightly better and the ICC ID is just a random number. Either way, the ICC ID doesn't really play too much of a part. I only mention it because you can derive the IMZ from it in the United States, at least. So what's an IMZ catcher? Basic idea is that it's a spoofed GSM tower. It's a fake base station. The idea is that when your phone is looking for a signal, it'll look for the strongest tower. It'll connect to the tower that offers it the best signal.  I'm only emitting about 25 milliwatts here. A tiny, tiny, tiny amount of power.  Another thing to bear in mind is that in GSM, it's the base station that picks all of the settings. So when you connect to my tower, it's my tower that gets to instruct whether or not to use encryption, whether or not to use frequency hopping, all of this kind of stuff.  That's fine, I'll talk plain text. Seriously, it's that simple. There's all kinds of stuff that the base station can instruct the handset to do. Please take my word on it that I'm not doing anything malicious here. This test is for functionality only. There should be no permanent changes made to your phones whatsoever if you do connect to the network. But if I wanted to, there's all kinds of stuff I could do. I could update your SIM card, all kinds of fun to be had. So essentially, if you've got the ability to deliver a reasonably strong radio signal and your base station will negotiate A50, which is plain text, you're pwned. There's nothing you can do about it. And there's a good chance that you won't even know about it. If I'm the tower, then not only am I your network, but I also control your handset as well to a pretty significant degree. The actual idea of an IMZ catcher has been around almost as long as GSM has. It was originally patented by Rodin Schwartz in Europe in 1993. I've never seen reference to any US patents for it, but either way, patents in Europe are just as public as they are here. So all of the details of this is all public. The main important point about this is that if you were to go to Rodin Schwartz and say I want to buy an IMZ catcher, they'll charge you a couple of million dollars. The equipment that I have laid out on the table here, by far the most expensive part is the laptop. Second up is the USRP at about 1500 bucks. And then I think the next most expensive thing is this $20 instant messaging device. So the whole point is that using these techniques, you can intercept phone calls for a thousand times less money than the commercial systems that do exactly the same thing. So quick note about the crypto involved in IMZ catchers. If I'm the attacker and I create the base station, you have a cell phone that connects to my base station. I just say disable crypto. I don't need to break crypto. I don't need any rainbow tables. I don't need any solid state hard drive for fast lookups. Nothing. I just say turn off encryption. It's that simple. In reality, the GSM specification does actually say that when your handset connects to a network that does not use encryption, it has to put up a warning message. But then if you read further in the spec, there's another place where it says, if you want to disable this warning message, set this little configuration bit in the SIM card. So every SIM card that I have ever seen in my entire life, and I've seen a few from various networks around the world, every single one of them has that bit set. Every single operator that I've ever seen, disables that warning message. So no phone. I've never seen a warning message on a cell phone that actually says you're connected to an unsyford network, even though the GSM specification requires it. So this is a deliberate choice on the part of the operators. The idea of it is that if you go to a country like India, in India, they don't support cell phone encryption. It's actually illegal. So obviously, you want to be able to roam in India, you want to be able to make cell phone calls. So your phone has to support A50. And if you're getting a warning every time that you connect to a new tower in India, you're going to be wondering what the hell is going on and hassling AT&T or whoever. So it's one of those areas where functionality and security are directly at odds. So note on spectrum usage. One of the issues that was raised with this talk in the press is that operating a transmitter on a US cellular frequency is a very big FCC, no, no. You get in a lot of trouble for doing that. Fortunately, we don't actually need to. The reason for this is there's four bands used for GSM around the world, A50, 900, 1800, 1900. A50 and 1900 are the two that are used in the USA, 900, 1800 are used in Europe. If you actually look at the size of those bands and the frequencies that they cover, there is an overlap between European GSM 900 and the United States ISM band at 902 to 928 megahertz. So I'm actually running my transmitter here as a legal ham radio transmitter in the, I call it the ISM band, but it's technically a ham radio band. And as far as your cell phones are concerned, I'm just a European radio transmitter. I'm a European tower. Your phones don't care that I'm in the States. They don't care that they're in the States. They don't care that they're on a completely inappropriate band for the location that they're in. They're just quite happily, hey, there's a tower, let's party. It's pretty crazy. So if you've got a European phone, if you've got a quad band phone, you'll see the network. If you've got a US phone that only works on US frequencies, you will not see the network. So the ISM band, industrial scientific medical, the idea of it is it's for very low powered devices that use very low utilization in a very low actual time on the air. They change frequency very rapidly, generally designed to be very non interfering. But if you look at the regulations, ISM is actually secondary in the band. It's a ham radio band.  So the noise is too much of a problem for most ham radio applications, so most hams dismiss it. But for our purposes here, we can run a GSM base station on a GSM frequency within a ham radio band. How do we do that? Well, first thing we need is a license. This URL is great. The licenses for the question set for the ham radio exams are all public. So if you go to this website, what they do is they just keep asking you the questions over and over and over and over and over again until you get them right. And if you keep getting it wrong, they'll keep asking you and if you get it right, they'll stop asking you. And it just beats the right answer into you. And you can sit down with this site for a few hours and walk into a ham radio exam and just pass it. I'd recommend that if you do want to get into this stuff, take the time to learn it, take the time to understand. I certainly learned a lot from taking my ham tests and I'd recommend it to all of you. As we're a ham radio operator now, we have a 1.5 kilowatt power limit. That's a lot. I have another amplifier that I've been using for RFID that's 600 watts. And I've yet to turn that on because it's a terrifying amount of power. Even 600 is too much. So 1500 should be plenty for anything. In terms of what we're actually allowed to transmit, technically we're transmitting an unspecified digital code. It's bits going back and forth between your phone and my tower. So in ham radio terms, you're allowed to transmit an unspecified digital code as long as the specification is public. And in this case, all of the specs for all of the various GSM protocols, they're all public. So it's all good. You're also not allowed to use cryptography. You're not allowed to obscure the meaning of the message in any way. So I guess by law, if I'm running my BTS in a ham ad, I have to disable crypto. Damn. No limits on antenna size, antenna gain. Basically if you can get your hands on it and run power to it, you're golden. The only thing you ever need to be careful of is RF exposure limits. The FCC publishes guidelines for what absorption rate people can tolerate safely. In this case, I am nowhere near those limits. This side is my transmit antenna. I think it's this side. And it's putting out a total of about 25 milliwatts. To put that in perspective, your cell phones, if they're on the European, if they're on the higher bands, the 1800 and 1900, they'll be putting out a watt. That's 40 times more. If they're operating on the lower bands, the 800 and 900, they're putting out two watts. So that's 80 times more. So the phone in your pocket is exposing you to significantly more RF than my big scary antennas. The only other real requirement that we have is that the station has to identify itself every 10 minutes. That's actually pretty easy to do because to be a ham compliant call sign ID, it's straight carrier wave, morse code, every 10 minutes, just more something else. We could have integrated into the USRP. Certainly the USRP is capable of it, but that's doing it the hard way. There's an easier way to do it. That being, you take a second transmitter, you tune it to the same frequency, you make sure that the power level of that second transmitter is slightly higher so that whenever that transmitter is on, it's effectively DOSing the GSM signal with a ham radio call sign. So all we need is an easily scriptable 900 megahertz transmitter. And as it turns out, this little pink instant messaging device is perfect. This is called the IMME. This was brought to me by Travis Goodspeed. They're fabulous little devices. They have reasonably good power output. Obviously, keypad and screen is helpful. No firmware security. You can program them with a good fat. Unfortunately, they don't come standard with JTAG and RF connectors, but that's easy enough to add. So yeah, we can write firmware for this. We can match the frequency because we've got control over that in software. And then we just need to mux the signals together and amplify it up. So I'll actually pause there for one quick demo. No, actually I'll come back to that one. So in terms of the BTS itself, so we've got the IMME for the ham radio side. What do we need for the GSM side? It's actually pretty easy. You need a USRP, universal software radio peripheral. These things are available online. They go for about $1,500 with the two daughter boards that you need. I'd also recommend if you're going to get into GSM, check out the clock tamer. The URL is up here. The thing about clock tamer is that in GSM, the handsets derive their timing from the base station. So the base stations have extremely accurate clocks and the handsets figure out how much their own frequency is drifting compared to the tower. So if I come along with a third party tower, if my frequency stability doesn't match that of the local towers around me, all of your phones are going to be calibrated to those local towers and you're not even going to see my tower because I'm, you know, maybe just a few kilohertz off. Clock tamer actually gives me plus or minus 100 hertz accuracy at 1.9 giga hertz. That's in its out of the box configuration. It's about 0.26 parts per billion accuracy.  Crazy, crazy, crazy accuracy. And it's all programmable and very flexible. It's highly recommended. On the software side, just a laptop computer, Debian Open BTS and Asterisk. Open BTS provides the soft, the GSM stack and then Asterisk takes the calls in from Open BTS and sends them out over the back hall as voiceover IP. It's a fairly basic base station. It does do voice, it does do SMS, it does not do data. And in fact for the purposes of this, this demonstration, I've even disabled SMS. Purely because there's no way I can get your caller ID easily. So when you send an SMS, yes I can route it out through the internet and connect it to where it goes, but the person who receives it is not going to know who it's from and they're not going to be able to reply. So I figured it was just easier to disable it, but the system does support it. So let's get the BTS going here. So I wanted to see if we can get some video here. Is there a camera we can get up on stage or do you need me to turn the screen around? Okay. So I'm actually just going to plug in my USRP now. That's all on. And then start the base station. Or try to if it would actually. Let's try this again. There we go. So Open BTS is up. I don't know how much detail you're going to be able to see on the screen here with the camera zooming in. One thing I do want to show you is the Timzies command. So I don't know if you can actually make that out on the screen. The command I typed was Timzies, T-M-S-I-S. What that shows me is a list of all of the temporary ImZs that have been allocated by the base station. In other words, how many people are currently associated with it. So you can see right at the bottom here, zero Timzies in table. So I've started it up clean. There's, you know, nothing there. Nobody's connected. A couple of other things I'm going to show you as well. I'm just going to turn this around so I can type. So a couple of other commands that I've typed here. Cell ID. That shows you that my mobile country code that I'm using at the moment is 001. In the GSM specification, country code 1 is test. I'm then using a mobile network code, an MNC of 01. So again, that's test. So I'm a test network in a test country. I'm operating on a non-European cellular, sorry, a non-American cellular frequency. And then if you look at the bottom here, the short name of the network that I'm starting is called Defcon 18. Some phones will display that, others won't. But the point that I want to make across is that at the moment this is in a non-hostile configuration. It's in a test mode. It's not advertising any known network. It's not operating on a U.S. cellular frequency. And certainly as it started up, nobody was connected to it. So I'll leave that running for a few minutes. If people really want to do a scan for the network, you can. But I prefer people to just leave their phones alone.  Because we'll, I'll come back to this in just a second and, you know, show you how easy it is to make phones hand over here. So we've got the BTS in test mode. How do we then make this into an IMZ catcher instead of just a random cellular network? Well, the way that cell phones identify the network is by two values. I mentioned them already, the mobile country code, mobile network code. Mobile country code, 310 for USA. There's a full list on Wikipedia for every country around the world. Three digit number, not really that hard to spoof. Mobile network code, again, two digit number, maybe a three digit number that you can look up on Wikipedia. Not really much security there. It's pretty trivial to change it. You can, I'll show you in a sec how to do it on open BTS. It's not hard. It's really not hard. And then once I've set the MNC and the MCC, I can change the network name as well. So that when it displays on your phone instead of seeing DEF CON 18, you'll see whatever network it is that I want you to see. In most cases, well, in some cases I've noticed that handsets will not hand across to the base station unless the short name of the network, the network name is entered case correctly. So it's kind of sad when the security of your cell phone calls comes down to a case sensitive string comparison. Not much security there. So that's really always involved in spoofing a network. So let's come over here and actually do it. Before I do, I'm just going to type Timsy's again. Wow. That's 15 people. 15 handsets are currently connected to my tower. And that's without spoofing any cellular network. So 15 people in this room are currently having their cellular phone calls intercepted by me and my BTS is not advertising any known network in the world. It's in a test mode.  One quick thing, raise your hand if you have an iPhone. Okay, if you do not have your hand in the air, you're probably not connected to my network. In my experience, it's generally the iPhones that connect most easily. It's actually been quite the bane of my existence trying to keep the damn iPhones away.  So, okay. So we have, oh wow, we now have 30 Timsy's in the table. You know, people are still handing over to this. So in the few seconds that it took me to explain why there's 15 people, 15 more people connected. It's insane. It's really easy to do. So let's spoof an MNC and an MCC. So I mentioned the cell ID command. So that shows you the MCC, MNC, location area code and cell ID. I can then do cell ID. Quick question for the audience. Raise your hand if you'd like me to spoof T mobile. Okay. Raise your hand if you'd like me to spoof AT&T. Should have seen that one coming. Okay. So I'm just going to turn this round. All I do is I type cell ID and then I give it the mobile country code. Well, we're in the state. So our mobile country code here is 310. And then I give it a mobile network code. Well, AT&T's mobile network code. They have several, but the most common one that they use is 410. So let's type that in. And then I'm going to leave the location area code and the cell ID the same. So that's going to be 666 and 10. That's it. I'm now spoofing AT&T. I could be a little more careful about it. I can do config. So here. The cell ID command here, 310, 410, 666, 10. That sets my mobile country code and my mobile network code. And then this command down here, config gsm.shortname AT&T. And as far as your cell phones are concerned, I am now indistinguishable from AT&T. So the question was how long does it take to hand over? That's kind of the point of the talk in all honesty. From this point, so at this point, we have an emcee catcher. I can sit here and over the next 20 minutes, half an hour, every AT&T cell phone in the room will gradually hand over to my network, gradually start giving me all your traffic. So from this point on, the only question becomes how can we make phones hand over more rapidly? In practice, it might sit here for an hour before any significant number of phones connect. So we want some techniques to speed it up. So at this point, we do have a simple emcee catcher. We're spoofing a cellular network. Clearly handsets in the audience are handing across to me. Does anyone actually try to make a call and hear the recorded warning message yet? One here, another at the back, another over here.  I'm getting all of your traffic. So how do we filter this down? Well, firstly, I now know you're emcees, so I can filter based on emcee. If I know the emcee of the specific person that I want to target, I can exclude everyone but that emcee. Likewise, I can do the same with the IMEI, which is the equipment serial number, the equipment identifier. I can say, you know, only allow knockiers to connect or only allow iPhones to connect. I'm not sure you can quite get it down to that level of granularity, but so you can say this particular IMEI is allowed to connect and nobody else is. So I could restrict it down to a limited set by, you know, various different parameters. As I mentioned, it takes time for people to migrate across. We can make it faster. I'm going to talk about some techniques for that in a sec. One major limitation that this current system has, it only intersects outbound calls. So when you're attached to my tower, as far as T-Mobile, AT&T is concerned, your phone is off. It has no signal. It's, you know, whatever. It's just not there because you're not connected to one of their towers. So when a call comes in, it'll just go straight to your voice mail. We can, we can get around this. I'll come back to that, but for the moment we've got, you know, outbound calls getting recorded. So how do we speed up handover? You know, we don't want to be sitting here all day watching everyone's phones handover. So, you know, what techniques have we got to speed up that process? Well, there's actually a few. Neighborless, changing lag, band jamming, receive gain. I'm going to talk about all of these individually. Some of them I'll demo, some of them I won't. But there's lots of different ways to do it. The first one is GSM neighbors. So each tower, each GSM tower, when a phone connects to it, the phone will retrieve from it a list of neighbors. And what that means is each GSM base station is on a specific channel, obviously. The, the base station will say there are base stations nearby on these other channels. And what your phone will do is it'll take that list of neighbors and it will monitor all of those channels and it will keep watching, you know, the signal strength on all those, those neighboring towers. And when one of those neighboring towers becomes a stronger signal, it'll hand over. So how can we use this to our advantage? Well, all we need to do is we know that the, the cell phone is going to be monitoring these neighboring frequencies. So if we do a survey of the local area and find out what neighbors are around, we can then compare that to what frequencies the phone can actually see, what towers it can connect to and, and whatever. And eventually we can find a channel that is advertised as a neighbor but perhaps is on the other side of the tower. So you can't actually see it from here. So I can put up my, my tower on a frequency that I know your phones are listening to and that I know there isn't a tower there.  We must have driven down the street and this tower is now closer. So I'll just hand over to it. So how do we do this? It's actually pretty easy. You get a Nokia DCT-4 phone, I believe. The 3310 does the two European bands, the 3390 does at least one of the US bands. What these do is they support a thing called network monitor mode. And what network monitor does is it effectively dumps a log of every GSM thing that the cell phone does. Every packet that it sends to the base station, every, every burst that it receives from the base station, everything. Every single thing that cell phone does gets logged. Doesn't allow you to interact with it, doesn't allow you to control it other than, you know, beyond what you can do on the handset already. But it does at least give you very, very detailed insight into what your phone sees on the GSM network. So you get one of these phones, you get neither a special F-Bus, M-Bus switching cable and a program called Gamu. Gamu is open source, it connects to the phone over this cable and just dumps out a trace in XML, which you can open up in Wireshark. I was going to demo it, but my 3390 has gone wandering. So what I'm going to do instead is just show you what the traffic looks like. So this is a capture that I recorded last night. This was of a handset connecting to T-Mobile. And I actually called it only partway through the boot sequence.  But you can see you've got all of the various GSM messages in here. And if I click on the right packet, let's try system information type two, which is that one. You can see Wireshark breaks it down nicely. And within this packet it actually says, here's my list of neighbors. So literally, you just take this phone, you turn it on, you connect the cable, you run Gamu, and then you look at the Wireshark trace and you've got a list of channels. You then compare that, you know, just literally turn a radio receiver on to each of those channels and see if you get a signal on them. It's not hard. And using this, you can find an advertised neighbor that's not actually in use in the local area and speed off handoffs by taking advantage of that.  And I don't want to do that. Certainly an attacker would have no such compulsion and could easily take advantage of this to his benefit. So we can find GSM neighbors and we can take advantage of that. Another way to speed up handoffs is the location area code. The idea of the LAC is it groups together a bunch of cells. So you'll have, you know, a whole bunch of cells in one specific area that advertise the same LAC. And in general, those will go to, you know, the same higher level controllers as well. But what happens is when the phone is, you know, monitoring all of these neighbors and, you know, if it just sees another tower or whatever reason it is to look at that secondary tower that it's seen, it'll see that if that tower is advertising a different location area code, that means that the cell phone has moved, at least as far as the cell phone is concerned. And if the cell phone's moved and it's moved into a new area, then it should really do a handoff. So from open BTS here I have complete control over the LAC. So I can just change the LAC and everyone's phone will go, oh hey, LAC's changed. We must have driven 50 miles down the road. Let's hand off to the new tower. So the more you change the lack you can, you can keep rolling the lack every, every few minutes just to entice more handsets. It's, it's not particularly difficult to do. I'll give you a quick demo of it. First up, let's, let's see how many handsets. So before we, we started spoofing AT&T, we had about 30 handsets connected. Now that I've got AT&T's network name, MNC and MCC, let's see how many handsets we have connected now. 24. Don't quite know how that went down. Timsy's due time out. So another command that I can try is load. And this is telling me, oh this is telling me that there's 24 Timsy's in use as well. So not too sure what's going on there, but we've certainly got a bunch of handsets connected. And then we can use the cell ID command again to, to roll the location area code. Turn this around a second so I can actually see. So my location area code was 666. I guess I should change that to 31337. And I keep the cell ID at 10. In fact I'll change the cell ID as well just so that the handsets know it's a new tower. And it's that hard. That's how to roll the lack. Not a complex operation at all. And then like I say, that will encourage handsets to, to, you know, believe that they've changed location and that should entice more handsets to, to camp across to the new network. We'll, we'll come back to that when, when we do the next stage and we'll see how successful that was. So what happens when the handset turns on? How does the, the handset first find its very first tower? When it, obviously when it boots up it knows nothing. It knows, it doesn't know where it is, it doesn't know what frequency it's on, doesn't have any neighbors to look for, doesn't know the current lack, nothing like that. So it does a very, very long scan over the entire band. And whatever towers it finds, the, the, it checks the MNC and the MCC tries to make sure that, you know, those are allowed networks based on, you know, what the SIM card will actually connect to. And then the signal strength as well. And it'll just, you know, connect to the strongest tower. Once it starts finding some towers, it limits the size of their scan. It performs a much smaller scan much more rapidly because it has some information about, you know, what bands are in use, what towers are in use, what channels to look for, all this kind of stuff. So an attacker can actually use this to, to his advantage because if you DOS, the cell phone system, in order to, to, you know, make people lose signal, when those handsets connect back up again, they're gonna perform this long scan. They're gonna perform this, this much wider band scan and have a much higher chance of, of connecting to the attacker's tower. So, how can we do this? Well, first off, we're only talking about second generation GSM, 2G. 3G has much better security, much, much, much better security. So if we jam the GSM band, then when we turn the jammer off, your handset's gonna perform a wider search. It's gonna perform a slightly slower search, a bit more chance of finding the tower. However, if you're on 3G, there's really nothing I can do. The, the 3G protocols are much, much stronger than GSM and it's a lot harder to intercept a 3G phone call. So we really don't want people using 3G if, if we're trying to intercept phone calls. So what we have to do is, is jam the 3G bands. If we jam the 3G band, your phones lose the ability to connect to a 3G tower and they quite happily drop down a 2G. So all you have to do, literally, is broadcast noise and block the ability to talk to 3G, at which point everyone drops down to, to 2G in plain text. It's like saying, well, if you, if you can't connect to port 22, then I just fail over to port 23. Seriously, you can, you can think of 3G as, as, you know, equivalent to SSH and, and GSM as equivalent to Telnet in this situation. So, yeah, it would be an accurate analogy to say that, you know, if you can't connect to the SSH port, just drop down to Telnet. That's effectively how, how cell phones work in this situation. So the question is, how hard is it to jam a cellular band? Really not very. All you need to do, really, is transmit noise. And when I, when I say noise, I mean a very specific thing. I don't just mean, you know, randomness.  Effectively, what we're doing is, is instead of, you know, removing the tower completely, we're just removing the ability to see the tower. We're, we're masking that with, with noise. Noise generators really aren't very expensive. I have one over here. Little, little thing, if I can do this without squishing my ninja badge. Second? No, it's all good. So this is a, this is a noise generator. This was $450 on eBay. And if I connect this to a power amplifier and I have a power amplifier upstairs and then connect the power amplifier into an antenna and I have antennas clearly, if I turn that on, that's rather a large disruption to cell phone service. I can, I can, I mean, the noise generator itself was, as I say, as it says, 450 bucks on eBay. The power amp was 400 bucks on eBay. Not, not on eBay, on the internet at least. That's a hundred watts. A hundred watts of wideband noise is a huge, huge, huge disruption. This is what it looks like. This particular noise generator has two modes. It has one for the, the 900 megahertz bands and one for the 1900 megahertz bands. So what you're looking at here is the trace from a spectrum analyzer. The lowest frequency on the left is about 500 megahertz and the highest frequency on the right is 2.5 gigahertz. And then as the line goes up, there's, there's obviously more power at whatever frequency that corresponds to.  That, that is effectively this thing transmitting on every possible frequency in every possible, you know, channel between about 850 and 950 megahertz. Turn that thing on and, and yeah, 850 and 950 just stops working. Likewise in 1900 mode. You can see again that the major peak is a little further over. It's, it's pretty clear that this does what we need it to do. So what happens when you jam a cellular band?  Of course I haven't done it.  If you were to do this, if I was to plug this thing into my 100 watt power amplifier and I was to connect it to an antenna and turn the whole thing on, it would probably knock out GSM, CDMA, 3G, Verizon, you know, pretty much every cell phone service there is for most of Las Vegas. If not further. So yeah, I, I'm not turning this thing on. The main reason that I have this is because it's a fabulously useful piece of test equipment. If you're trying to classify filters, you put white band noise into a filter and as long as it's nice and smooth, you can compare what comes out and, and very, very accurately characterize your filter. That's what I use this for, not for, for, for DOS. The thing about band jamming is that there is no way to defend. It's impossible, cannot be done. Short of swamping it with, with more and more power. You do only need a short burst, few seconds, but it's still way, way, way too offensive for, for what I'm doing here. So as I said, 100 watt of amplifier and a reasonable antenna would probably knock out Las Vegas cell phone systems. So another technique that we can use to, to make handsets hand over. There's a, a command that the BTS can send the handset that basically says, treat my signal as if it was stronger than it actually is. Meaning that, if, if I just, let's, let's say, you know, on a, on a scale of, you know, plus 50 to minus 100. Let's, let's, um, anyone who knows RF will, will understand why I'm, I'm choosing that range. Um, but plus 50 to minus 100. Um, let's say my signal is coming in at minus 80. Really, really low. Um, I can say to your handsets, just, just add a hundred to that, would you?  Ah, it's fine. You're the strongest tower around now. I'll connect to you. It's, it's ridiculous and it's, it's, again, it's another great example of some of the instructions that a BTS can send a handset. Um, so, you know, I don't even necessarily need to be the strongest signal. I just need to have a signal that you can pick up and be telling you that I'm the strongest signal. It's, it's ridiculous and the handset will comply. It has to comply because that's how GSM works. When the handset gets an instruction from the tower, it complies with it. Um, the, of course the attacker can make use of this. Um, you know, of course it, it means that he has to use less RF power to, to, to win the strength competition with the local towers. Um, Open BTS doesn't actually support it yet. Um, so I, I, I won't demonstrate it here. Um, this is actually the, the essence of the Rodent Schwartz patterns on IMZ catchers. There was a, a case in the UK where someone was selling IMZ catchers. Um, Rodent Schwartz sued and it, it effectively came down to this one technique. Um, spoofing MNCs, MCCs, network names, it's, it's all trivial but, you know, this, this one technique is the, the, the one that's patented. So I mentioned earlier that we, we don't see inbound calls. We, we only see outbound calls. Effectively the IMZ catcher is a completely isolated cellular network. Um, as far as your carrier's concerned, your phone is off, it has no signal, it's just, it's not there. So of course they're going to send calls inbound to your voicemail. Where else are they going to send it?  So the attacker doesn't see the, uh, the inbound calls. So the way that we get around this is obviously if you're connected to my, my tower, um, my tower has to authenticate you, therefore it, it will ask for your IMZ and your phone will quite happily supply it. So I know your IMZ. What I can then do is I can, you know, go to AT&T and say, hey, here's my IMZ. I'm, I'm spoofing this guy over here but you don't need to know that. This is my IMZ. And I know that this guy's not on the network because he's on my network, therefore it's perfectly safe to do this without you seeing two phones. So I, I claim this IMZ. The problem with that is that we don't know the secret key in the SIM card. We don't know K.I. Um, and what's going to happen is the, the, when I claim that IMZ to AT&T or T-Mobile, um, they're going to send me a random number, a 32 bit number, just a challenge. And what normally happens is that challenge gets passed to your SIM card, gets encrypted with your secret key and then split into two parts, half gets returned to, to the tower or it's just kind of proof that you know the secret key and the other half is used as the ciphering key. Well, what I can do to exploit this is I can just pass that random challenge along to your phone. Whereupon your phone will happily, you know, encrypt your secret key with it and all the rest of it and send the result back to me. But the result doesn't come back to me as, you know, here's the, here's the answer. Um, the, the, the, the session response I do get just kind of here's the answer but the, the secret key I have to crack. And, and here's the, the, the great thing about IMZCatchers as opposed to, you know, crack in an air probe and those kind of things. Um, crack in an air probe, how many folks saw that release at Black Hat, the, the A51 cracker? So the, the big limitation that that thing has is that it doesn't work on frequency hopping base stations which virtually every base station in the civilized world is. So it, it kind of doesn't have real world applications. Well, in this instance, I'm the base station. I set the hopping sequence. So I can just say to you, okay, let's negotiate A52 because I can break that really easily. And then let's disable hopping so that, you know, I, I don't have to worry about that. And then I can use these rainbow tables to crack your secret key. Whereupon I recover the session key. I now know the session key and the, the session response, which was the authentication response and I can just reuse it all to the carrier. And as far as the carrier is concerned, okay, it took a few seconds for me to, you know, establish a challenge to your handset and then crack it and all the rest of it. But at the end of the day, I provided the right response to the carrier. So hey, I must be you. It's, it's, it's not implemented in this system yet, but it's, it's definitely possible to do. It's, it's the technique that commercial MCCATS, MCCATS is used to catch inbound calls. Certainly, yes, I, I cannot do that on this system currently, but it is absolutely possible with MCCATS. So just a little more on breaking that session key. It is the only time when you're using an MCCATS that any cryptography is needed at all. The majority of the time I just configured my base station to just negotiate A50, just disable encryption. What do I care? If I negotiate A52, A52 is very, very easy to crack, much easier than A51. So, you know, that gives me a very quick way into your handset. Alternatively, you may reject A52, regard A51. Well, clearly A51 is, is still, you know, crackable and we can still do that. But in either case, any calls that originate from your phone come to me as plain text. So what's the solution to all of this? You know, how do we, how do we fix this? The reality of it is that there, there is no good solution. Not in the context of GSM. GSM is broken. It is the telnet of cellular systems. In order to fix GSM, you'd have to redesign GSM. And if you're redesigning GSM, you have to upgrade every handset. You have to change every tower. You have to change the networks that live behind them. So, why bother if you're going to that much effort to redesign everything? Why don't you just move to 3G? The, the solution here is 3G and, and later protocols. 3G authentication is much better. Obviously it's three and a half G, 3.9G, LTE, all of the, the, the subsequent protocols build on that as well. The primary solution here is turn off 2G. Unfortunately, how many people have Android phones? You've seen the setting that says use only 2G networks. Yeah? Supposedly saves battery? How many people have ever seen a setting in a phone that says use only 3G networks? Okay, BlackBerry has one. Certainly Android doesn't, iPhone doesn't. So, how can we be secure here? Certainly 3G is, is, it's showing cracks. It's not been broken broken. The, the Kasumi cipher has been somewhat broken. But the, the 3G protocol hasn't. So, yeah, just use 3G. Look for that icon on your screen with a little 3G. If you see that, then you're, you're pretty good. Alternatively, just treat it like a data network. Just, you know, layer another, put another layer of crypto on top of it. Treat it like voice over IP. Just use it as a data network. Treat it like the internet. Encrypt everything that goes across it. Just, just don't trust it. And then in the long term, the, the, the big solution is to just turn off 2G. Which will happen eventually as, you know, three and a half G and 4G are deployed more widely. Hopefully, you know, now that, that, you know, I've demonstrated this, there'll be a little argument that, you know, it's totally possible to intercept 2G phone calls. So hopefully we'll, we'll spurs some uptake of 3G and, you know, we'll see where it goes. So one final demo. Let me just see how many Timzies we have connected here. 17. Okay. So people are actually handing back to the normal network. That's unusual. Certainly there was a lot of handsets connected to start out with. It's possible that I actually, you know, mistyped AT&T. I think there's some spaces in there. So it's entirely possible that your handsets are connecting to me and going, oh, you're, you're not spelling AT&T correctly. I'm out of here. So, by the way, certainly, you know, feel free to, to make some calls through it. The only limitation is that you have to dial one in front of the number or, you know, whatever country code you want, you're only limited by the, the $20 of credit in my SIP account. Feel free if you've, if you've not heard the recorded message, then you know, like I say, connect to the network and, you know, have a play. It's, it's, it's there for the next couple of minutes while I take some questions. So yeah, have fun.


This is the SugarBeat Report, bringing you the latest information from NDSU throughout the SugarBeat growing season. SugarBeat producers almost always welcome timely rains, but Cercospora Leaf Spot also enjoys warm, moist conditions. Now is a great time to check the fields, according to Ashok Chanda, Extension SugarBeat Pathologist with the University of Minnesota and Northwest Research and Outreach Center in Crookston, Minnesota. Ashok, has the weather been favorable for Cercospora development lately? And how much Cercospora are we seeing in the fields? If you think about the week of July 24th, we received some rainfall, which means that we have the temperature and relative humidity that's perfect for Cercospora to establish. Now if you look at the daily infection values from July 24th to 27th, they were very conducive for establishment of Cercospora in the fields. It takes about 10 to 12 days from the time of perfect conditions for Cercospora Leaf Spot to show up. This week would be really ideal for you to go and check how much Cercospora has developed in the fields. For example, all it takes is about 3% of the leaf tissue that's covered by Cercospora Leaf Spot and then you can expect some economic damage in terms of year-loss to Cercospora. What fungicide application strategy should growers consider applying at this time of the season? Most growers are doing an amazing job this year to keep up with their fungicide applications. I know some of them started really early just at the time of canopy closure, which is ideal to start Cercospora Leaf Spot in a fungicide application. The key thing to remember is tank mixing is critical, right? You have some fungicides which only work when they are on the leaf tissues and some fungicides just enter the leaf tissues and they can provide some protection inside, right? That is the reason we have to combine a fungicide such as a triazole fungicide with a broad spectrum contact fungicide such as Mancozeb or TIN, right? That's why the tank mixing is critical. In the number two, when you're applying fungicides, adequate coverage, you know, for example, most of the Cercospora develops in the lower part of the canopy. So you need to use at least 15 to 20 gallons per acre for the volume so that you can get adequate spray coverage so to get better disease control. The third one is spray intervals, right? Let's say if you applied a TMI fungicide plus Mancozeb, then you have at least 10 to 12 days until you put on your next application. But for some reason, you get like half to one inch rain the very next day, then all you have is the protection from the systemic one, which is the TMI fungicide. In those cases, you may need to narrow the spray intervals. But if you have only applied a contact fungicide such as TIN or Mancozeb, so you may need to even shorten the interval up to seven days so that you can do a new application. Are you seeing any other elite diseases this year? We are mainly finding Cercospora leaves, but in the fields, but you know, historically, this is kind of on the low levels this year. But in 2022, we saw some fields with Alternarian and Stemphilium leaves for a very low frequency, which we have not picked up anything this year. But if you're not sure what you're dealing with in your fields, you know, you can always send in a sample, leaf sample, whatever spars that you're seeing, and we can help diagnose. And you should bring the samples to the Northwest Research and Outreach Center, Sugar Beet Pathology Lab in Crookston, Minnesota. Thanks Ashok. Our guest has been Ashok Chanda, Extension Sugar Beet Pathologist with the University of Minnesota and Northwest Research and Outreach Center in Crookston, Minnesota. This is the Sugar Beet Report, bringing you the latest information from NDSU throughout the Sugar Beet growing season.


Hello, good afternoon everyone. So in this talk, I am going to cover about CIP, its different work groups and the work we are doing especially in as part of security work group. Plus, there will be some highlights and updates from other work groups and how CIP security work group and other work groups are working together for achieving some targets. So let's see. Yeah, so the main agenda points would be discussing about CIP work groups and IEC 6243 activities in CIP. We have done some of the activities. We have completed some are in progress and then achieving IEC 6243 compliance for CIP. And for this, we have some challenges from open source or software perspective, where there are some challenges in terms of development processes and some other stuff. So we will see some details. And then we are just reusing all the open source component to achieve this compliance without developing any new components. So the idea is basically to just reuse already available components and achieve this compliance. And then as part of this story, we have we are also developing IEC 6243 layer, which has security packages. And it is part of ESR CIP core. And this also has a lot of other features to be added in our future. So the motivation behind CIP is always to collaborate with other open source projects and communities work closely with upstream communities. For example, reproducible builds and similarly other upstream communities and then contributing back to open source community. So this is how we collaborate with other communities. And we work together to solve problems. And CIP has upstream first policy. So any issues CIP users find they can directly report to upstream or in fact to CIP as well. And finally, when the some solution is found, it has to be first upstreamed. And then it comes back to CIP and to CIP users. So the main motivation behind CIP is to collaborate in open source way and solve common problems all the players in the industry they are facing. So the key challenges basically, which are common across the industry is having an industrial grade software, which can be very reliable and functionally safe. And it can have real time capabilities. And then sustainability, where the product can be used for very long duration and backward compatibility and supporting standards like IC and maybe other security standards, it could be from different domain. And then security and vulnerability management firmware update. So these are the key challenges. And CIP basically focuses on these areas to address these key challenges. And they develop some software which can address these key challenges. So to address these key challenges, basically, in CIP, we call it open source base layer, which consists of CIP core packages and CIP kernel. So as part of CIP kernel, CIP had its own kernel maintenance team who maintains CIP kernel. And periodically, a specific long term supported kernel is selected. And then it is further maintained for 10 plus years. So recently, kernel 5.10 was selected for this maintenance. And on top of that, we have CIP core packages, which currently primarily supported by ESA CIP core project, which develops reference images for multiple architectures. And there are already multiple reference hardware supported by CIP, based on x86, ARM64, ARMHF. And those architectures continuously, we are adding up based on the CIP members request. We have certain framework to accept our new reference hardware. And that way it is accepted. Sorry. So the main focus is developing open source base layer and then maintaining it for a long time. So as a CIP platform, basically, the main objective is to build and maintain a pre-production base layer, open source base layer, which is having an industrial grade quality, which can be used in products which were industry runs on those kind of products. And CIP members and other users can use this layer and they can implement commercial products using this layer. CIP also maintains its own preempt RT forked kernel, which is further collaborated with the RT community. And it's being used in several CIP products, CIP based products. And then there are multiple reference hardware supported by CIP. And currently, basically, we keep doing testing on these reference hardware for all the supported kernels whenever some updates are there. So then further, this testing is done through Lava Framework and those test results are updated through kernel CI. And providing super long term support for 10 plus years is one of the key features of CIP platform. Now briefly, I will touch upon CIP work groups. So in CIP, we have governance structure where we have governing board TSC. And then further, there are multiple work groups who focus on specific areas. So we are basically from CIP security work group and focusing currently in IC 6243 compliance. Security work group members closely work with CIP core, CIP kernel and CIP testing and other work group members to achieve those requirements, compliance requirements, as well as how to update for security and how to support vulnerability and sharing those vulnerability updates regularly with the CIP users. And that way, regularly, these work groups keep meeting and keep working. Then we have CIP core work group who is responsible mainly for creating the reference images. And the key goals basically to maintain CIP core package for long term and provide reference implementation, which is based on CIP core packages. And this keeps enhancing, I mean keeps increasing the number of packages. So any CIP member company can propose to add additional packages based on certain criteria. And similarly, other work groups can propose to adopt additional packages. And then CIP core work group basically does some investigation and understands how well the packages maintained and accordingly it is either selected or rejected. So we have a certain process called package proposal, which is followed for that. So this is how our CIP core packages are selected and then reference images are built. So I will go to the next slide, which explains about the package proposal package selection process in CIP. So this can be done by any CIP member who wants to have additional packages. For example, some members wants to have open SSL, some member wants to have some backup related package or additional features. So those packages are first checked how well they are maintained, how many open CV is or open issues are there. And based on that CIP core work group decides whether to accept that package or reject that. And once it's accepted, then it is further maintained. In CIP core work group, there have been several activities recently like collaboration with the reproducible build team to make CIP images reproducible. And as part of that, we solved some problems like removing DevConcast files and removing less temp files and fixing change log time stamp problems. These were creating problems to make CIP images reproducible. So these problems are solved, but still there are few more things to solve to make CIP images reproducible. As part of this, we are also collaborating with the reproducible build teams and we are getting inputs from them. So this activity is one of the main activity and it will continue. Recently, CIP core started supporting Debian bullseye based reference images and supported KMO ARM 64 secure boots. I think this was one of the main topic in previous CIP sessions. And then adding IC layer to adopt additional packages which are proposed by a security work group. So these are some of the recent activities CIP core members have been working on. And in future, there will be further activities which include development as well as defining policies for the compliance of IC6243 and achieve this IC6243 compliance. And then there are some issues still to be solved for reproducible build which are like anti-config cast files and root FS file time stamps. So these are still some of the problems to be solved to make CIP images reproducible. So this is in the roadmap. And then further supporting and discussing next version of Debian bookworm and working for creating the reference images for this. And then as part of security work group, currently the main focus area is to do the compliance and for IC6243. So key goals are basically to investigate IC6243, 4-1 and 4-2. So this has been done and working with certification body so that some of the work we already did we'll see more details in coming slides. And then identifying certain packages which we already did some of the packages and we created IC layer. And then as part of the process making the proposal and making those packages part of the CIP core. We are also discussing other initiatives to start in CIP security workgroup including investigation of additional security standards like NIST. Some part of it we already did to meet some of the IC requirements and identifying security hardening practices. So we can achieve some of the IC requirements as well as we can improve the security in CIP images and collaborate with other security workgroups to get more inputs and to engage with them to bring those strength to CIP. So this is how various like multiple workgroups work together in CIP. Like CIP security workgroup we investigate some of the packages to meet IC requirements. And then we discuss with certification body. And then we discuss with CIP core CIP kernel. And then we decide whether the package is suitable or we should make some other choice. And finally this decision in this process CIP TSC members also involved to make the final decision for some of the things. And that's how this overall process works and that's how we operate. And we regularly meet our like security workgroup, CIP core members and CIP kernel workgroup members. We regularly meet by weekly and we discuss upon the current issues, current activities, future activities and TSC meetings. We discuss about each workgroup progress and future roadmaps and planning. In CIP security workgroup we added multiple security packages as part of IC compliance and they are part of IC layer. So recently we have added some packages related to Google multi-factor authentication. And we are discussing to add some of the packages for supporting backup requirements and data data at rest encryption requirement. And then in parallel we are working with the IC certification body for completing the gap assessment action items and then going for final assessment. So as of now the plan is by end of this year CIP will go for final certification by end of this year. And then we will be completing the assessment for assessment based on the current software stack. So most likely currently we are having Davion Bullseye and CIP kernel 5.10. That is the most probable candidate for the assessment. And next we are preparing for final assessment to complete the final assessment. We have to work with certification body and understand the current status of the items. We already completed and the processes we have. So we found in our investigation there are few things already available from Davion and from Upstream. So for example some of the packages Upstream developers already do static code analysis. Then from Davion security tracker we found there are some security related processes required by IC62044-1 which are also like helpful to meet some of the requirements. And then once this is done then CIP will publish the reports guidelines as well as additional packages requirement so that CIP users can utilize that and go for the final assessment for the end products. So this would be the next focus for CIP security workgroup. Now as part of security workgroup our mission is basically to provide a validated platform and guidelines and evidence for CIP users and also for meeting the compliance requirements to the testing and evaluation. So these artifacts this information can be reused by CIP users to easily achieve the compliance to IC as well as it will reduce the significant it will significantly reduce the effort for IC compliance and they can reuse the guidelines and fill the gaps. Whatever requirements cannot be met in CIP being a platform they should be met by CIP and product. So usually for any product to get the IC certification these are the top level steps where product team has to investigate about IC standards and for that from CIP they can get a lot of reference material documents and that can be reused and then working with certification body. So again this can be reused from CIP and then adding capabilities. So it depends lot of things depends upon the end product requirements but several requirements are already achieved through CIP so they can be reused by CIP users such as IC layer is one of the one of the layer where multiple requirements are met by adding those packages. So CIP users can use those capabilities and build upon those capabilities to meet end product requirements. So this IC related activities we started sometime back and we already completed lots of activities doing the investigation of IC 4-1 and 4-2 and then working with certification body for identifying the gaps in current capabilities of CIP and current processes which we follow and after doing the gap analysis there were few gaps identified and most of the gaps we have covered by adding additional capabilities plus additional process documentation those things so that's already available for anyone to look at it and so basically after this the final step is to go for final assessment with some certification body and we are in the final stage soon we will be engaging with some certification body for final assessment. So during this investigation we encountered there are still lots of gaps in terms of if some open source based product wants to achieve a certain IC kind of compliance. So for example development environment security is one of the challenge from open source perspective because in controlling the development environment in open source is quite difficult we never know the kind of development environment being used by individual developers how it is controlled how it is secured what kind of security is applied so this is one of the challenge to use open source components for getting some compliance then IC also expects several secure design principle related requirements so how the component was designed how secure are the interfaces how it will make sure all the authentication or all the identification kind of requirements or any data flow is always protected so this is also one of the thing which is challenging to achieve and then assessing and addressing security issues is something like it's partially already being done as part of Davian security team so for each security issues vulnerability when it is reported it is expected that it should be evaluated for its side effects and like what will be the issues in different products if that issue remains open and how immediately it should be fixed whether it is applicable or not so this kind of analysis has to be performed by some someone so this is currently being done by some of the Davian security teams so we are currently planning to just reuse that and then it also expects doing threat modeling for components some components which might be vulnerable or which are coming from let's say third parties so again this is some of the challenging things in open source where most of the components we can say it comes from third parties or other developers upstream developers so identifying such components and doing the threat analysis and identifying those paths where it can be vulnerable and then making sure so it's like quite challenging to do such things in open source based on components and then another thing is security update so how frequently updates are provided by the components and how it is made sure it is always up to date so these are some of the challenges which we found during investigate when we were doing the investigation for IEC requirements so we have worked on them and we also had discussion with certification body how we can address from open source perspective so they also don't know many things because many open source based components have not gone through such kind of certifications so they also worked and they also did some brain storming so for different things for example development environment security basically we we defined as part of CIP we defined certain policies to restrict the merge privilege so anyone cannot just push the code so this is how we up to certain level we control the development environment and of course there are some assumptions like inherently the upstream developers are protecting their own development environment and then security and principle related requirements are like not easy to meet but as an alternate option it was suggested by certification body that if we make sure that static code analysis or the reviews are done in such a way that all the components which might be risky are properly analyzed so this we found many components already doing this static code analysis in upstream then similarly for assessing and addressing security issues we found Deven security tracker already has several policies and some of them are quite well documented but still there are gaps probably those need to be filled so that lots of such requirements can be met they they are not just to meet certain policies certain guidelines they are just also equally important to address the security concerns so in CIP basically we are using Deviscan for tracking CVs and in CIP kernel it supported since long time and regularly CIP kernel workgroup members share the CV updates in CIP dev mailing list so that's how CIP users get the updates and this is how this requirement is met because as part of CVE multiple such analysis of assessing and addressing security issues is already done so this is how partially it is met and then for threat modeling we did some threat modeling how currently CIP works and how our CIP GitLab repositories are protected and how we are making sure we have only couple of members those those those are active members they have the merge privileges nothing like anyone can push the code and similarly for security update management we provide reference implementation as part of CIP but of course the actual implementation has to be done by CIP users it is just a reference implementation it can be used by CIP users to further enhance it and customize based on the product requirement so after this analysis we started working on creating IC layer and as part of that as we can see here anyone can try this IC layer by doing a Git clone of ISA CIP core and then creating a security image and then we can currently run in camo and soon we are planning to support this on real hardware and then it can be tried on real hardware so this is list of security packages currently we have already added to enhance the security capabilities and this list will further increase as we progress in the investigation and as we discussed with the stratification body so anyone interested can try this IC layer and recently we have also done some documentation and some additional security configuration which can help you CIP users to further customize it and here we have another GitLab repository where we are maintaining all our IC documents all the documents whatever we are creating they are maintained in markup format so that it's easier to maintain easier to customize and here we are following the process like any CIP users or CIP developers create the document then it is reviewed and then it is merged so all the documents are kept in this repository and this is the format we decided to use for all further documents so whatever documents will be created in future they will be in the same format so as I explained partially earlier like in CIP we do CVE handling this is also one of the IC requirement to have the CIP sorry CVEs updates provide CVE updates to CIP users so in CIP kernel currently through this repository anyone can see the details and for CIP core the work is currently in progress partially there was some implementation using Debian DAB scan but still this work is in progress and in future we would be having this as well so then we will have a consolidated list of CVEs which will be shared with CIP users and accordingly they can decide to update or to upgrade the packages to further enhance the security so the one of the main motive of CIP also to just reuse don't develop any new things so we are just reusing open source components without modifying anything of course when we are finding certain issues we contact to respect to upstream developer and we work with them to fix those issues so this is how we work and in IC also we are to to achieve IC compliance also we are just using all the open source components in IC layer so how CIP users would benefit from the compliance we are still in the process of quantifying it how we can quantify like what kind of actual percentage of benefit in terms of cost or effort it will reduce but that is something still in progress so once CIP is compliant to IC then it will provide a secure foundation as platform for CIP users so when CIP end product is developed on the compliant platform it's basically has its it has basically inherent security capabilities and of course it will reduce significantly on the effort for IC compliance and certification for CIP users because once this is completed there will be multiple artifacts which can be reused which are like currently we are developing as part of security work group multiple documents are already developed for example we completed threat modeling document we completed hardware guideline document for addressing for this two requirements so these are the produced artifacts as part of this activity plus IC layer which are the technical capabilities to be added in Easter CIP core so from this compliance CIP users will immensely benefit once this is completed and on top of this CIP users can add their product specific capabilities and of course CIP users will have the choice to suggest to CIP to add additional capabilities or additional packages or whatever so that can be further discussed within CIP so yeah we are almost in the end of the presentation so we have CIP booth running we are certain CIP based softwares CIP based devices having certain demo so we invite all attendees to visit booth and get more information about CIP and if we just compare CIP with other distributions so we can see there are a couple of things which are quite good or quite comparable where we have a dedicated team of kernel maintenance and we promise to provide the updates up to 10 years even when the long term support is ended by upstreams so this is one of the key feature or key objective of CIP because after certain time updates are not available then open source components become vulnerable and they become outdated and obsolete so to solve this problem CIP started this support and then we will have soon IC certified platform which can be further used for end product certification and we are closely monitoring CVs for all the features CIP kernel uses which are basically contributed by CIP members and those CVs are regularly updated to CIP users and this way we keep CIP users up to date and informed and for certain packages there is ELTS support based on the CIP members requirement which is also quite important because again when the support is ended by upstream it's it becomes difficult to get any updates and those components becomes outdated and CIP has its own testing workgroup CIP test workgroup which is actively testing regular updates on multiple associates with the different architectures and those test results are published to kernel CI and they are available for anyone to look into and that is how this regular software updates then testing on those things keep working and then we have multiple players who support CIP and this is how we can differentiate CIP from other distributions so basically we have these members who are currently CIP members for additional information these are the further links we have CIP mailing list CIP dev where we regularly communicate about CIP tools CVs and other things plus we have CIP website and there we have further each workgroup blogs where you can find more information about these things and most importantly CIP has a huge list of GitLab projects belonging to CIP kernel CIP core CIP security CIP testing there are multiple projects where you can find lots of information useful so that is all about the season any questions yeah maybe yeah yeah so we have was like raspberry pi we got one black and couple more plus some CIP member specific hardware are supported by CIP so we have a list of hardware in CIP website which are currently supported and there are certain requests by CIP members to add in supported list additional hardware yeah so we are targeting level 3 but when we had discussion with certification body so they are saying it depends upon the final final investigation done by certification body so then accordingly they will provide which level CIP qualifies so currently the target is to have our security level 3 so if there are no more questions we can yeah please yes we could discuss accepting that thanks okay any more questions thank you thanks for joining


Dr. Virgil Griffith and Vikram Verma will present designs for the L4 contract programming language based on Deontic modal logic. Hello, everyone. So we're working. Are we sitting down? You're going to sit down. Okay. So if you guys are going to sit down, so we're going to, I think we can go to our first slide. I mean, this is actually, so there's going to be a lot of math in this talk, just like accept it. Where's our slide? Well, okay. We'll tell you in the meantime. So we're here to tell you about, we're developing a brand new language for contracts. And so it's sort of from a company called Legalize. Legalize.com. Legalize is an open source project with delusions of one day being a start-up. And so originally, so you can talk to us all there. So I'm kind of like the face and Vikram here is the brains. So we can just go ahead and go on straight and we can go to the next slide. And we'll tell you about the gist. Is there a clicker? Oh, okay. Wait. Buttons. Okay. Great. All right. So yeah. So we are giving you a lovely start-up here. So originally, our goal was to make a little programming language for lawyers to use. So the idea is that you would write your little contract in a little high-level language. The compile button, and you would get an English legalese out of it. And that was kind of like the big idea. And so I was friends with Vitalik over here, and they were doing even more sophisticated things with formal verification. So there's a nice joke. The joke is what do you call runtime debugging of a smart contract? And you think about it. And the answer is litigation. And you know, yeah, I know, I know. It's funny. But no, it's actually totally true.  And basically you just can't have them.  So yeah. So you do lots of formal verification. And so we're like, oh, well, let's go take all of our stuff for lawyers and give it to you, to give it to you, Etherians, because you're probably going to be our power users and you need it even more than the lawyers do. So yeah. So here we are. So we're making a custom DSL just for, you know, permissions and obligations. Surprisingly enough, some of the lawyers are actually already biting into this. You know, we said it's going to be technophobic. But hey, some of them actually get it. And so this is like, you know, a real offer. And they use some of our code. So oh, wrong button. Okay. So this is just kind of a BTDub. So the red is what we are modeling here, sort of all possible contracts. And then we have the dApps. And then we have the purple is where we can help you out. So our ideal world is where you'll write your little contract and you won't even think about Ethereum. It'll just be, oh, there'll be these agents with these obligations, blah, blah, blah. And then it will just compile. And you can, for the most part, just not worry about it. And in the future, you can even get your English contract as well. So okay. So let's go this one. Okay. So first people ask, well, we love Solidity. Do we really want another language? And the first answer is, oh, well, you can still have your Solidity.  You can kind of think of it as, say, using, say, C versus, I guess something like Python, I suppose. That's not quite exactly right. But anyway, the idea is that you want like a high-level language for doing high-level things and you don't want to think about the rest. But if you're doing novel things and you want to be close to the bottom, then you should still use your Solidity. So we use SQL. Sort of an example for why it's a good idea. So you can imagine querying your database in C or JavaScript would be very unpleasant. But doing it in SQL is lovely. So we're going to give you an SQL for contracts. Okay. Yeah. So that's why you want to do it. Yeah. And the cool part about this is that, so the reason you don't want to do this is because, so first of all, you could eventually one day compile your Ethereum contracts to English. And number two, we could eventually start getting normal, like normal lawyers using Ethereum because here's the cool part. Because the Ethereum system is more reliable than a judge's brain.    So this is our start. Go. So we have rough consensus, but not running code. And the rest of this talk is essentially going to be a fairly high-level literature review of ways of expressing agreements and ways we can reason about them and eventually ways in which we can compile those into code, which is interpreted in a way that preserves those semantics. I am budding wrong. So CL is a logic-based formalism for expressing contracts. And this is its syntax. You can read that as saying that a contract either indicates an obligation to do something, a permission to do something, a prohibition from doing something, the conjunction of two other clauses, or some contract become active dependent on some other action having been performed. And we can look at the structure of obligations where we have two parameters, C and alpha. Alpha is the thing you're expected to perform right now. And if you do not do that, then you have to fulfill the reparation clause C. That clause C can be the far-right clause, which is unfulfillable. And if you ever get to that point, you're in breach of contract. Actions are basic propositional variables, which can be either expressed in terms of concurrent actions, i.e., you do things at the same time, or you sequencing, you do one thing after another, or you do between one of two things. To make that concrete, here's an example of a fairly simple clause. This expresses that if you do A, you must then perform B. And if you do B, you must not perform B. And if you breach either of those commitments, then you are in breach of contract. And just to make some of the later slides more legible, we sometimes omit the residual clause when it is unfulfillable. So there have been several semantics that have been defined for this language. Originally it was equipped with branching semantics. And the idea is there is that you can reason about which expressions can be substituted for each other and the sorts of things they imply. For example, you can take an obligation to perform some action is equivalent to the prohibition from not performing that action, which seems fairly simple. We're going to be focusing here mostly on trace semantics, where the idea is I want to say that some sequence of actions is consistent with a given contract. You can read this as saying the sequence of performing A and then later B as a claim, rather, fulfills the contract that we sold before. There are sets inside that sequence to accommodate concurrent actions. And I seem to have misworded the slides, but essentially this satisfaction defined relation is defined pretty much as you would expect. If you are obliged to form some concurrent set of actions, then you should perform them or otherwise you must fulfill the reparation. If you are obliged to perform some sequence of actions, you should perform one and then the other or otherwise fill that reparation. And this sort of reasoning is enough to derive that claim we made before, if you'll admit the somewhat aggressive normalization here. So to show that if you do A, you must do B, and if you do B, you must not do B in rough sequence. Well, we know that the sequence A, B does not involve initially doing A, and so that clause is trivially fulfilled. And in the other clause, because we do A initially, we have the residual obligation of having to do B, and that's fulfilled by the second component in the sequence. I'm going on the wrong order. It's the other way button. It's the down button? Yes, the down. Thank you for the down button. So that's fairly well. But the cool thing about this particular satisfaction relation is it's decidable, and there's a rendering onto automata so that you can essentially just pass these things to this machine, and it can tell you whether you're in compliance or in breach or whether you have residual obligations which later actions in the trace may or may not let you fulfill. And the cool thing about these graphs, this is an alternating automata, but it doesn't have to be, but never mind because time, is that you can do a bunch of analyses about these which tell you properties about your contract. So you can say that the sequence AB satisfies it, and so does the sequence A, A and B, and so does the sequence BA because that validates in both automata. You can say further that it's satisfiable because there exists a trace which is compliant. Another interesting thing about this particular automata is that if you consider the sequence in which you initially perform both A and B at the same time, there's no valid extension of that trace. And so with respect to your standard trace semantics, that's probably fine, but we see something here. We see that at this coordinate, we have the diantech obligation to perform both B and not perform B, i.e. the contract is telling us that under some sequence that we have conflicting obligations, and this is somewhat undesirable. And so there was another paper which essentially extended the semantics to account for the diantech responsibilities at each coordinate and essentially assigned what patterns you need to fulfill in order to not have a conflict, and this should be true of all traces. You can render this into an automata, but you're mushing things together so that all the obligations are in the same place. And then you just pattern match on these to determine whether you're saying two things which you should not be saying at the same time. OK. So no, I need to thank you. Oh, you need the clicker thing. So this is the one that I liked best. So this one's a little neat because the previous one you saw, it gives a really nice flexible way of representing contracts.   And in particular, so this is a novel approach that allows you to say, oh, well, when someone doesn't do their job, it says so. And you can see exactly who that is. This is nice because then you could hypothetically etherealize judges. And this is the one where the lawyers would fully join us, and that would be great. So right now, the way things go is that you would write your things in a little contract. But when it goes awry, you still have to go back to the traditional legal system. So this idea is, oh, you have to go to the legal system at all because you know exactly who is to blame for every possible path through the contract. And that would just be great. So I'll show you roughly how it goes. So this button. So basically, there is a verdict, which is V. And there's two ways a verdict can go over a contract. It can be a check mark, which means everything's great.  And basically, in every contract is defined as a function that maps a sequence of events or sequence of actions sigma to either a check mark, meaning it's great, or a timestamp, and then someone fucked up. And yeah, and that's it. And so you can say, oh, well, OK. So you can fully describe the ways through a contract through all these different sigmas. OK. And you can do cool, cool, cool composition contracts, too. So you can say, oh, well, so you have contract V1 and V2. So you can and them, or you can or them. So that's a little operations there. And basically it tells you how they go. And you can do more interesting things. So you can say, oh, so here's probably the coolest one is to look at this application clause. So you have agent. So this is this. Oh, go back. There you go. So you have agent E1 executing these actions, K. And it takes parameters, x little thing over it. And so it's due within some little window D. And if it wins, sorry, and if it satisfies all of it, then it says, oh, there's still, you get time left, Z. So you have like five days to do something and you finish it in three days, Z becomes two. And then it goes on to the next contract. So you can sort of chain contracts together. In this recursive form. And that's like really neat. So it's kind of this idea, oh, so we're kind of doing the beginning here. We were doing sort of like what are the atoms of contracts? So I was like the periodic table. And these give you all different ways that you can chain them together. You can do a chemistry of contracts and make cool molecules out of them.  Yeah, so this says this is really fertile. OK, yeah, so here's an example one right here. So this is an NDA contract. So this appreciate board. So it takes one argument, the employee, and it says, oh, if you ever get a disclosure reported, when it takes an E. And if E is the employee and it's happened within the past five years, then breach. And that employee is at fault. And the little then employee says the employee as a blame. And it says, oh, and by the way, and it starts now.  You could do it in English, French, Mandarin, whatever, or Ethereum. And yeah, and it would all just work. OK, cool. So this is basically in here for the languages and math people who want to know how you actually implement these ideas. That's it. This is for you. And so there are some complications in the way that you can merge contracts. There are some restrictions. So for example, so you have different contracts, but the people who they blame aren't always the same. You can't combine them. And that's kind of a limitation. And that's annoying. And we should pay a PhD to figure that out. OK, so this is sort of the next one. This is how this connects to the upcoming literature, which we'll probably hear about probably tomorrow on specifically Ethereum. How much time do we have? Because the things say it's like 30 seconds. That's correct. I'm just going to skip to the next slide. And deep embeddings are cool. And we have a very well-defined idea in terms of the space of variation in the contracts you can express, what indicates good behavior. And the rest is basically relates to the compiler. And you want to be able to say that normalization with respect to a logic behaves equivalently in your source logic and in your compiled output. And we can do that and stuff. All right, last one. You have to hit it. All right, so this is the end? Oh, no, the other button. There you go. So OK, so this is basically our thing. So basically, we're here. So we are basically formalizing contracts sort of in the broad sense. We expect you, if you were thinking to be our power users, so if you want features, you should let us know because we're designing this. And yeah, and we'll do like free work for you. And if you're interested in this kind of thing, come hang out with us. And if you want to follow us, there's our mailing list and there's our email address. Yeah, come talk to us about languages sometime.