This video is presented by the Liquor and Cannabis Regulation Branch. It provides a demonstration of the process that Police of Jurisdiction will use to review special event permits through the LCRB's Liquor and Cannabis Licensing Portal for Police. Our previous video provided an overview of the review process for a special event permit. In this video, we show you how to navigate our online licensing portal to review special event permit applications. To use the online licensing portal, all users must have a Business BCEID login. Each Police Jurisdiction should identify one person to be the Business Account Manager responsible for managing all BCEID credentials for their officers. If the Police Jurisdiction does not already have a Business BCEID account, the Business Account Manager will register for one on the BCEID website. For instructions about registering for BCEID, see the document titled Important Information for Police of Jurisdiction Special Event Permits. Once the Business BCEID account is set up, the Business Account Manager will use those BCEID credentials to log into the LCRB licensing portal. When the Business Account Manager sets up their account in the licensing portal for the first time, they must click on the Request Activation button in the dashboard before they can begin working in the licensing portal. The Business Account Manager will also set up Business BCEID access for individual police users as each police user who will review special event permit applications must have their own Business BCEID login credential to use the licensing portal. More details on this can be found in the Business BCEID Account and Profile Management Guide. This is the website to access the licensing portal. After using your Business BCEID to login, you will land on the homepage. Here are some areas of the portal you may use. Your account profile is accessed in the top right corner. The All Applications tab lists all special event permit applications within your Police Jurisdiction. The My Jobs tab lists those applications that have been assigned to you. Let's begin in your account profile. In the top right corner, you will see your name and your jurisdiction. Click on the drop-down arrow and select Manage Account. This is your account profile. The section Police Contact contains your information. This is the email address you will be notified through when an application has been assigned to you for review. It's very important that you fill in this information the first time you use the LCRB licensing portal. If there is no email address listed here, you will not receive an email notification when a special event permit application has been assigned to you. The section Police Details contains information about your jurisdiction. The section Police Addresses displays the address, phone number and email address for your jurisdiction. This is the email address by which the Police of Jurisdiction is notified that there is an event application in their area. It's important to ensure that all information on this page is always up to date. Use the Save and Continue button to save any changes you make. Returning to the home page, let's now go into the All Applications tab. This is a list of all event applications in your Police Jurisdiction. You will see when each application was submitted, the name of the event and the start date of the event. Under the Status column, Issued means that a special event permit application has been approved, the fee has been paid and the permit has been issued. It's important to note that events with attendees under 500 people will be automatically approved by the system as long as liquor service is not requested beyond 10pm for outdoor events or 2am for indoor events. Pending review means that the special event permit application is awaiting review by your Police Jurisdiction and possibly by the LCRB. Approved means that the special event permit application has been approved either automatically by the system or manually by the Police and the LCRB. A fee has not yet been paid by the applicant. As such, the special event permit has not yet been issued. This page will soon include a feature to help you filter the applications according to their status. Under the column Assigned, if the application has been assigned to a member of your Police Jurisdiction, you will see that person listed here. Unassigned applications must be assigned to a specific person before they can be reviewed and a recommendation made for approval or denial. The system will permit any Police user to assign an application to someone within their jurisdiction. To do this, click on the arrow to open the drop-down menu and select an Assignee. Once you click on the Assign button, that person will receive an email notifying them that the application is awaiting their review. Use these arrows at the bottom of the page to navigate to subsequent pages as there may be more events in your Police Jurisdiction. To look at a specific application, just click on the event name. Now that we have looked at the All Applications tab, let's look at the My Jobs tab. The My Jobs tab lists all applications that have been assigned to you for review. If an application needs to be assigned to someone else, go to the Action column. Click on the arrow to open the drop-down menu, select the new Assignee and click on the Reassign button. The application will then disappear from your My Jobs tab. Click on the event name to look at the details of its special event permit application. You are now looking at a specific application. The box on the right shows you the current status of the application. This Reviews Are Assigned to section will show you the status of both the Police and LCRB Reviews. Here you will see the status of the application once again. The event type will also be listed here. For example, if the event is a birthday, wedding or music festival. Here you will also see the size of the event. A small event has up to 250 attendees, a medium event has between 251 and 500 attendees and a large event is classified as having over 500 attendees. This section also tells you how many locations the event covers. Under General Application Information, you will see the police jurisdiction where the event is happening. In some cases, an applicant may enter incorrect information about the police jurisdiction and your jurisdiction may receive events that belong to another jurisdiction. For instance, an application may come to the Vancouver Police even though the event is within the jurisdiction of the West Vancouver Police. If this happens, use the drop-down menu here to select the correct police jurisdiction based on the event address. After making this selection, click on the Change City button. The application will then be removed from your My Jobs list and the new police jurisdiction will be notified about the application. The section General Application Information will list the applicant's name, phone number and email address. The eligibility section displayed here will show you information about the event start date, the applicants serving it right or special event service certification, the organization applying for the permit, the occasion, whether the venue has a liquor license and whether the event is taking place on public property. Some events may have multiple liquor service areas. For example, a wedding could have one service area for cocktail hour and another service area for the reception. Each service area will be listed here. Details in this section will also include whether there will be minors in the area, the number of minors as well as the dates and times for the event. The Liquor Fees section of the application will show you the applicant's estimated liquor quantities and financial information based on their liquor purchases and sales estimates. Once you have reviewed the application, return to the top of the page. You may now either recommend approval of this permit application or recommend denial of the permit application. If you recommend denial of the application, you must provide a reason. The applicant will be able to view the reason provided. If you recommend approval of the permit, you also have the option to recommend the addition of terms and conditions to the permit. To add a term and condition, click on permit terms and conditions. Type one term and condition in the box, click on the Add TNC button and repeat this process adding each term and condition individually. When you have added all recommended terms and conditions, click on Save TNCs and you will return to the summary of the application. To complete your recommendation of approval for the permit, click the Complete Review box. If an application requires review by the police and no action is selected, then the permit application will remain in the system awaiting review and will not be processed. This will not be the case for automatically approved applications. That brings us to the end of our review of the LCRB licensing portal for special event permits. If you have questions about applying for a business BCEID, contact the BCEID Help Desk. If you have questions about how to use the licensing portal or about special event permits, contact the liquor and cannabis regulation branch.


The best thing about the HR Operations team is they're so supportive, everyone works together and they help you no matter what. The HR Operations team, we have a really welcoming culture. So everyone sort of brings you in, we have a really good party theme, it's brilliant. The culture here at Golduck is super supportive.  So our HRRO team made it really easy for us to ask questions. You're really nervous when you start, but they made us super duper comfortable. We feel like a team, but we're not interns there, we're actually workers. Going into the workforce is a different experience, so you do need to learn a lot of professional skills. And Golduck did offer a lot of training and development in terms of leadership skills, emotional intelligence and awareness, resilience and focus, which is very helpful. So I got given the responsibility of doing a project. I honestly had no idea what I was doing, and then they implemented someone that actually ran that project, so I was able to go to them for help.  Golduck will actually have people there that you can go to for help. The culture at Golduck is incredible, it's not like anything else you'd expect in a corporate sort of environment. They're also welcoming and so happy to see you, it's amazing.


I'm Sergeant Major of the Army, Gridston, and I'm here today at the Pentagon with six-stringed soldiers. To all the soldiers and families around the world, I just want to say, happy holidays.


Welcome to Zenibus. Zenibus is a BC based publicly traded license producer of medical and recreational cannabis that is positioned to become a global competitor in cannabis production and distribution. This is the location in New Brunswick and they have 3.5 million square feet in land and premises combined for the entire company that can be converted into production space in British Columbia, New Brunswick and Nova Scotia. Following the full buildout of these facilities, Zenibus will have a design capacity of approximately 479,700 kg annually. If facilities build out and optimize, potentially become one of the largest license producers in the world. Strong distribution network, multiple supply agreements, innovation and commercial relationships positioned for continued global growth with 400 plus full-time and part-time employees in four locations across Canada. This is a company that is poised for bigger and better things. Zenibus operates with integrity, respecting all laws and regulations governing the cannabis industry and respecting the local communities where it operates. In 2018, Zenibus became a founding partner of the Center for Medicinal Cannabis, the CMC, a UK based non-profit organization advocating, educating and lobbying for the implementation of a fair, responsible and evidence-based medicinal cannabis regime within the national health systems in the UK. The CMC promotes health, advances science and guarantees full patient access. Zenibus is a member of the global cannabis partnership, a collaboration among government agencies, industry and stakeholders to develop a worldwide social responsibility standard for the cannabis industry. Zenibus has a commitment to deepening relationships with first nations across Canada. Zencraft Grow, a program through Zenibus, has a commitment to helping communities establish legal micro cultivation facilities. Take a look at all the facilities. Zenibus is a company that is on the rise. If the facilities are fully built out and optimized, they have 3.5 million square feet in land and premises that can be converted into production space. You are looking at the Langley facility with 2,091,880 square feet. They are currently selling dried cannabis and they have under development cannabis oils, food and drink, hemp CBD, health and beauty, pet care and wellness, concentrates and vaporizers. Stay tuned for Zenibus. If you're not winning, you're not watching. This is your boy Rich. We bring you the winners and we bring them to you first.


How do you empower your customers to use your OptaPlaner application? If it runs on your machine on local host, they can't use it. You need to host it somewhere. Why not host it in the Cloud? Let me show you how to deploy it as a pod on OpenShift, the open source container platform built on Kubernetes. OptaPlaner comes within a sorted set of QuickStart demos. On optaplaner.org, you can find these by clicking on the link to the OptaPlaner QuickStart GitHub repository. In this repository, if you scroll down, you will find an overview over all QuickStarts. There's a number of use case QuickStarts, and there's a number of technology QuickStarts, as you can see. If you scroll down, you will see, for example, the school time table in QuickStart, where we need to assign lessons to rooms and time slots. If you scroll down further, you will see a screenshot of the facility location problem, where we need to decide where to open new stores, etc. Maintenance scheduling to assign maintenance jobs to crews, call centers, to who will pick up which phone. Vaccinations scheduling to assign a vaccination schedule appointments to locations, and so forth, order picking to decide which route to take through a store to pick up all of the items. And of course, the vehicle routing problem to assign the, in which order which vehicle goes to which location. So if we click on this particular link here, we can see we have the vehicle routing problem here, and notice how the directory of this QuickStart is use cases vehicle routing, and we'll need that in a second. So now let's try to run this QuickStart, where you can see the screenshot here on OpenShift, so we can share it with other people. First, you need an OpenShift instance. To get one for free, go to OpenShift.com and click on the try button. Then choose developer sandbox, where you get a free 30-day OpenShift instance. Let's start your trial. Then log in, then get started in the sandbox, launch it and start it. Go to your developer sandbox. This is the OpenShift web console. There's an administrator view and a developer view. In the developer view, in the topology screen, I can see all of my deployments, none so far. So let's add one. When I click on the add button, I can import one from a GitHub repository. So let's use this, and I'll use the GitHub repository as my source of truth. For now, I'm just going to use the Optoplanar QuickStart URL, but I could of course use my fork instead, right? So if I just fork that repository, make some changes. I can actually see the effect of those changes and deploy them on OpenShift too. Now, I'm going to, in this show advanced GitHub options, I'm going to specify which of the quick starts I want to run. So in here, there's a context directory. And as I explained before, the vehicle routing one is in the context directory use cases vehicle routing, but I could choose any of these other examples to run those on OpenShift, but let's do the vehicle routing one. So I'm going to write here use cases vehicle routing and let's deploy that. Here we go. You can see right now it's being built. So this is the deployment and you can see here on the bottom left that the build is pending, right? Now the build is running and if you wait a bit longer, you'll see that once it's ready, we can click on the open URL button and try it out. This might take a few minutes. The build is ready. It's green as you can see. So let's open the application. Here's the vehicle routing application where we deliver a number of items to these blue circles across the city. And we need to do that with vehicles coming from these two depots. So let's click the solve button and Optopener will try to find the optimal solution to do this for us. You can see here there's, this is the distance it takes currently with the solution it's currently proposing. And as we give it more and more time, it actually reduces the distance to find a shorter and shorter path. Now the beautiful thing about this URL is that it's no longer running on local host. Let me click this stop resolving here for a second. It's actually now running on it hosted on OpenShift. So we can actually give the URL to somebody else and they can try it out themselves. Let's add a few more deployments. I deploy three more quick starts, the call center quick start, the maintenance scheduling quick start and the school time tabling quick starts. You can see I now have four deployments, each one pod, and they're all running happily on OpenShift. So let me open the maintenance scheduling one here. You can see it's running and it's about assigning maintenance jobs to crews and when they should do those jobs. So just click the solve button and you can see that Oploplanar starts optimizing this, taking into account all of the constraints and so forth. And again, this is on a URL I can share with others. If you wanna learn more about this, just go to oploplanar.org. Thanks for listening.


Hello, everyone. So I'm Peter. I work for Red Hat on Python. Great job, by the way. And today I will be talking about byte codes and stacks. You might not have seen the talk on the board downstairs, because that's a late addition to the conference. Also, you might have been to a talk that is a bit more advanced than this one already, so I apologize for that. Hopefully, this will get some of the basics a bit clearer. Not very good timing at the end of the conference, but bear with me. So I will be talking about how Python actually takes the codes you've written and manages to do what the code says. So we'll be looking at the compiler, the abstract syntax tree, tokenization, at the execution model, which is frames, and so on. This is for Python version 2.7. There are always little tweaks between different Python versions to all this. So if you're using a different version, not everything will work exactly the same. Also, I've uploaded the notebooks I will be using to the EuroPython website. So if you have some more time, then you can just play along. Right. So I have this little Python module. It does very simple stuff. It assigns some variables, prints something, and it defines a function. So this will be using this for examples throughout the talk. Now this is just a piece of text. This is just some bytes or some Unicode characters sitting on your disk. Then you tell Python to run it. So what actually happens? Python opens the file, reads the text, and the first thing it needs to do is to tokenize, which means cut the text up into very small pieces. Actually, how many of you have taken a compiler's class in school? Almost half, I guess. So I guess you'll be a bit bored. How many have taken a compiler's class on Python? None. Okay. There are just a few differences to the traditional model. So tokenization, cutting the source text into little pieces that we can then use. There's a module for it. You can run the tokenized module. It will give you something like this. So all the information from the original file, let's say this equal sign is an operator. It occurs on line one between characters two and three. So like this, the text is cut up into little pieces that are called tokens that the rest of the process then uses. Now a little difference from the traditional model that you will not find in other languages is if you have indentation, traditional languages would have braces at the beginning and end, which then get converted into brace tokens. In Python, we have indent and de-dent tokens. So the indentation is actually detected in the tokenization phase. If you have some text between parentheses where indentation doesn't matter, then the tokenizer doesn't emit these indent and de-dent tokens. So there's a bit of cleverness already built into the tokenization step. If you'd like to do this from Python, you just open the file, you call tokenize dot tokenize, and you get all the information to play with. This is really nice if you're, for example, writing a Python-like language that has all the same tokens. You can just use tokenization for free and then build some kind of parser on top. So speaking of parsers, that's actually the next step that happens. Now you have a stream of tokens. You need to turn it into an abstract syntax tree. Now there was a talk about abstract syntax trees before. Is there anyone who does not know what an AST is? Okay. Maybe I should have written my abstract a little bit clearer. So an AST, as I guess you all know, is a representation of what will actually happen in the program. There's an AST module which can parse the text. So there's just tokenization and the parsing in one step. Gives you a module object which has some fields. In this case, it has a body and inside that body, we have my assignment, assignment expression which is a function call and a function definition. Python itself has an AST dump function which is not really useful because it just puts everything in a single string. There are lots of modules on PyPI that make this a little bit better to work with AST pretty as something I just found at previous versions of the stock had the code actually in there. It's not hard to find. So here's the structure of my code. There's an assignment with a target and a value, an assignment with a target and a value, expression which is a call. I assume all of you have seen things like this. So now we have an AST tree. The next step to do with this AST tree is to compile it into byte code. Again, I'll ask is there anyone who does not know about compiling to byte code? A few people. Okay. So let's run through this. Again, I have this module, I have my AST and I can call the built-in compile function which will take this AST and package it up into a code object. What this takes is the AST tree, a file name suggested it can tag the code object. This is where it's coming from. Backtraces then can use that information. And there's a mode. I'm not getting into that in this talk. So this will give us a code object. A code object is something Python can run. So if I do exec of the code object, it will actually run all the code contained in there. Now, what is inside a code object? There's a little function called code info that gives me most of the things inside there formatted pretty nicely. So it has some meta information, some file name. It's also used for functions. So it has lots of stuff about arguments, what kind of information goes in. Some internals, number of local variables, stack sizes is an implementation detail. It has flags to say what kind of features this code object has. For example, if there are any free variables or nonlocals, so it needs to reach out. Or if in Python 2 there were two kinds of functions, one was faster. So the type of the code object is encoded in these flags. We also have a tuple of constants. So whatever constants are present are put into a tuple and then they're referred by an index. We also have names because inside the code object usually Python refers to everything by numerical index. When it needs to print a back trace or generate the mapping of variables to values, it will look here and get the names of the actual variables. If I write my own function, now I guess don't spend too much time reading this. This just prints out all the attributes of my code object. There's a bit more. There's lots of the same information we had before, but there's something that this module hides from us. One of those is the code which we couldn't read anyway, but this is the actual instructions. This is what Python will then execute as your code runs. Another thing we have is the Elno tab, which is a mapping of the bytecodes to line numbers. Again, when a stack trace is generated, Python doesn't keep track of lines, but of where in the bytecode it is, and then it uses this line number table to map back to individual lines. That's mostly it. Whenever I have a function in my module, as I had had before, it gets put in, well, the code object for that function is compiled separately and put in as a constant for the enclosing module. Then what happens is when that function is created, when the dev statement is actually executed, this code object gets packaged into a function. This is where that is taken from. If you want to look for information on that, you can just get it out of the constants, and flags are a little bit different for functions than they are for modules, for example. I talked a bit about the bytecode. Let's go a bit more in depth. If I have my AST again, my bytecode looks a bit like this. It's bytes. It's just numbers from zero to 225. If I print them out as actual numbers, they become a bit more readable. You can see a bit of pattern here. It's always some big number and some small number, big number and small number, right? Actually, the bytecodes come in pairs of two bytes, so it's not actually a bytecode. It's a word code. It has units of two bytes. It's always an instruction and an argument. The disk module can tell us what all these numbers mean. First, we have the 100 and zero. The 100 means load a constant, and the zero is which constant this will load. This was for the statement A equals three. What this needs to do is load the number three. That puts it onto a stack, and then it stores that value into the variable A. So this does two instructions, load a number, store the number. Similar for the second line, for calling a function, it just gets all the arguments of the function. It gets the function itself. And in this case, I was multiplying something, so it calls multiply, and then it calls the function, and because we're not using the return value, it gets rid of the return value, right? So bytecode is just a set of instructions that Python follows linearly as it goes along. You can also run the disk module from the command line, get the exact same result. You can also use it programmatically, so if you do get instructions, you get nice little objects that tell you what each individual bytecode means. So this is pretty similar output to what we had before. So now that we have our bytecode or our information about what the program should do, what Python does is it saves that because all this parsing is quite an expensive operation. Python will save this, cache this, so that next time the same module is loaded, it doesn't have to parse it again. So serialization is a bit like, I guess at this level most of you know it, but it's a bit like JSON. You get some values, you can write them into a file. This doesn't use JSON. It uses a module called Marshall. So Marshall has pretty much the same interface as JSON. You call dumps. You get some bytes corresponding to whatever you put in. Marshall is specially made for Python code objects, so it can only serialize simple stuff like tuples, numbers, code objects themselves. Anything mutable will not appear in this dump. So if your program creates a list, there's no constant for that list in the bytecode, there's just an instruction to create a new list. For immutable stuff like tuples numbers, the codes are already in there. So I skipped a bit. Where does Python put all this? It puts it in a PYC file. Since anybody not familiar with PYC files, everybody is great. So this is what a PYC file looks inside.  If I list what the serialized version of the code object is, also a list of bytes, if I compare them, the PYC file will have a header on the first section, and the rest is just the Marshall's, the serialized code object, right? So we can verify. The first 16 bytes are a header. The rest is just the code object. What is this header? The header is mostly there for cache invalidation. So when you change the source code, Python has to check if the old cache is still valid. If you change it, it's not valid, and it has a bit of information to check if we're still fresh. So the first four numbers are what's called a magic number. It's the same for every Python version. It's called import libutil magic number, and this just tells Python, you know, this is a PYC file for this particular version of the byte code. If you run a PYC file with a different version of Python, it won't load. The next two files are in Python 3.7, usually all zeros. These are flags, because there are a few different versions, few different formats for PYC files that do a different kind of cache invalidation. Usually what you get would be the zeros. The next four bytes are a number of seconds from 2000 something from the Unix epochs, so it's a timestamp. So whenever you change the source code, it's timestamp when you change, and Python will know that something changed. Of course, if you do many changes in the same second, you might run into trouble, which is why we have the last thing in the header, and that is the size of the original source code. So if you add something, the size should hopefully change, and the cache will be invalidated. This is not perfect, but it works in most cases as anybody had problem with PYC cache invalidation. Wow, that's many more than I expected. So for you who raised their hands, there is now in Python 3.7 an option to use actual hashes of the source code. For this, you set some flags, use the compile all module, it has an option to use hashing instead, or to not check anything at all. So if this is not okay for either their options now. All right. So that was caching. How much time do I have? About five minutes. All right. So with that out of the way, I will talk a little bit about the execution model. So we have the code object, which has all the instructions, and the code object is immutable, which of course is different from functions. If you have a Python function, you know, I have this funk in my module, I can put custom attributes on it. It will remember them. I can do mostly anything in that. I can do the same thing with the code object. That's immutable, and that's actually shared between all functions that are defined on the same line. So if I have a loop and define functions in that loop, there will be different function objects with, they might have different defaults for their arguments. They might have even different names. The attributes we set on them might be different, but they are sharing the same object. So they're different. If I call them, they can do different things. But the code, the actual instructions are the same because for each function definition, that serialized code object, that module will just have one code object that will be shared. Now, so I have an immutable code object. I have a mutable function wrapper on top of it. That supplies the name and the default arguments. And every time I call a function, there's another object on top, which is called a frame. Now, the frame will remember what function is executing, where in the function Python is currently, and where to go when that function returns. So let's see. The best way to look at this stuff is in the import module. I have a function that will get the current frame and write some information from it. So what we got is a frame object. It has some code. It has the last instruction. So this is the position in the byte code where this frame is. It has a line number, which is actually not stored in the frame. I think it's computed on the fly when I ask for it from the position. It has some local variables, and it has the frame of the function that called this. So in this case, this is a frame for my Jupyter Notebook cell. Now, the interesting thing about frames is that they are mutable. So when the function is executed, the current instruction number changes. So whenever I printed this line number, that corresponded to this line. If I do this multiple times, I will get different line numbers. So as the function is executed, the frame gets updated. Also, the locals might get updated. If I set a variable, I will get that in the dict of the locals. All right. So all this is packaged up in my frame object. For the back, the back is the function calling this frame. So that will, in this case, give me my notebook shell. That's a place to return when my function is done. This is, of course, used for printing tracebacks. When you get an exception, this chain of frames is walked back and you get information from all the frames visited. And I think I don't have too much time left. So if you have any kind of questions, I'm aware that... Okay. So I'm aware that this was a bit quick. Originally, I gave this in three hours and I could go into a lot more detail. So I hope to do this at the start of the conference to get some kind of background for everything, but that didn't work out. So if you have any questions, if you want to go into more detail, if there's something that sparked your interest, then either ask a question or talk to me later. Yes, of course, but let's first thank the speaker. Thank you, Peter. Okay. Who's going to first ask a question? Who's going to be first? Okay. So thank you for the talk. Actually, I would probably hate person asking such a question, but I will try still. And do you think the things you've shown could be useful in like regular Python programming for optimizing or debugging or just interesting? Yes, they will definitely be useful. When I asked how many people had trouble with the PYC cache invalidation, I was really surprised. And obviously when you're debugging that, it helps to know what the PYC actually is and why it's giving me stale information. Also for debugging, obviously it's a lot more useful if you are writing a debugger than if you're using one, but it still helps to know how the things are executed. What happens when you define a function? There's something that's compiled ahead of time and then it's wrapped up in a function and then you get a frame whenever a function is called. I think this is good knowledge to have an idea how the computer works. It definitely helps in debugging if you have a better knowledge of the internals. As any of the modules that you've imported to give us the talk and to show us all those amazing things actually written in Python or are they all written in C? It depends. A surprising amount of them are Python wrappers on C libraries. One of them I've shown you is inspect. And inspect, I believe, has okay, if I call it from the command line, Python dash inspect, is it inspect? Yeah. Then it'll actually give you the source code of Python modules. Right? So this is how you could check. But yeah, most of them are Python wrappers. My question is regarding the interpreter. The information that you presented regarding byte codes and so on, are they specific to normal Python interpreter or it's shared by PyPy or it has nothing to do with the interpreter at all? All right. This is something I actually forgot to say at the beginning. All of this is specific to Cpythons. Specifically, it's for Cpython 3.7. It should stay the same for 3.7.1, 3.7.2, but it can change dramatically even across Python versions. For example, I think at Python 3.6 we got the word code where each instruction is two bytes long, which improved speed a bit before the byte code sizes were variable according to if the instruction took an argument or not. So that just threw off all the tools that had to deal with byte code. All of this is specific to Cpython and also usually subject to change. So anyone else? So you talked about how it gets to byte code from the original code. What happens after that to get to the machine code that actually runs? Oh. Was that too big a question? Okay. So what happens if I'm in the frame if Python is actually executing this? There is no machine code involved. It stays byte code and the Python interpreter is inside there is a giant loop with a C-switch statement. So it's just a bunch of ifs and it just looks at the current instruction and calls a C function or calls some C code that values the instruction. Nothing gets compiled to machine code in Cpython. So we have time for one more question, I think. Okay. Do you have the three-hour talk somewhere? Is it video or something? I don't think I do. Okay. But if you organize a meet-up, then let me know and I can maybe come over. It's really interesting stuff and I always get interesting questions from people who have a bit more time to look into this more deeply. So I would be interested in maybe getting that recorded. One short question maybe. Very short. Do you have any links or places we could go to to look up more information about this topic? Yes. If you found this interesting, then it's uploaded on the Europe Python site. So notebooks are there. And I have a little summary that sometimes has a link, for example, the full grammar specification. Also, most of this you can find in the Python documentation. That's supposed to be very informative. If it's not, then file a bug maybe or contribute. Or if you have a question, I'm always happy to discuss things. Either you're on the conference tomorrow maybe or by email. Thank you. Thank you very much. Let's make some noise.


The leash I have today is only, actually, I go all the way off the edge of the stage, so it's enough rope to hang myself. That's good. All right. I think we're going to go ahead and try to get started, modulo two hours, but I think we're ready to go. Let's see. Lots of ground rules. I'm Bruce Potter. I'll have an intro slide later. It's obligatory. You have to do it so people know who the random guy on the stage is. I gave this talk at Black Hat basically the same talk a couple of days ago. So if anyone here was at Black Hat, I apologize now, and you can go see another talk because this will largely be me just screaming and ranting like before and not saying anything of value. The one thing that was, I think, kind of shocking to me is that this talk should have, well, it was received very well, and it shouldn't have been. I should have been lynched. Last year I gave a talk at DEF CON that was about why you should use Windows if you care about security rather than using Linux, and I lived. So this year I've tackled something that I hope to be equally as confrontational and prove that I can, indeed, at least drink the crappy beer and live to tell about it. So I was going to dress up as church lady, but when I started to pass that idea around to people and say, could it be Satan? And people didn't know who the church lady was. They thought I was a little crazy.  All right, so clearly I should have dressed up as church lady, but it's your loss, so I apologize. Black and white ball on the other hand. You'll see me dressed up like church lady on Saturday. Other odds and ends, not really. First off, don't believe anything I'm about to tell you. It's my obligatory slide. For those that know, where did I get this quote from? Liquor store. I heard it. Someone said liquor store. Wow, someone's actually seen this before. I was at a liquor store buying some $5 whiskey, and there was Buddha staring at me, rubbed his belly, and he told me this. It's interesting.  And I think it was largely due to the fact that we don't have a lot of discipline in what we do in this particular community. We kind of shoot from the hip and say, look at the cool stuff we can do.   In the same sentence as my employer was used. So there'll be no F-bombs at all, none, zero. Anyway, so there used to be this problem with people kind of saying random stuff that wasn't necessarily true. We have a different problem now. We have a problem where the security community is very big. There's a lot of money in it, turns out. There's a lot of money in offensive and defensive capabilities.  And Microsoft and AtStake and all these people got together and formed this thing called the Organization for Internet Safety. They drafted this thing that was a counterpoint to the RF policy about full disclosure, and everyone debated this, like it was profound and interesting and whatever. Couple years later, it turns out that this is the wrong argument to have, because now we're all selling our exploits. We're selling them to companies, know nothing against 3Com and the other companies that are out there that are buying the exploits, but we have a different debate on our hands. We're not exercising full disclosure in the same way that we used to, and that really can change the motivation of the people that you see up here on stage. I have my motivations. I'm biased. Clearly, I'm giving a talk pro-trust and computing at DEF CON. I clearly have a biased and potentially chemical imbalance, but we really have to pay attention. Who's on stage and why are they telling me this? Why are they ranting about these things? And you've got to ask yourself, when you see all these talks, what's that person trying to do? What's he trying to accomplish?  Be cynical, right? We're cynical about code. We're cynical about firewall rule sets. We're cynical about routing protocols.  So just think about it.  Disagree. I encourage you to be as confrontational as possible within reason. Simple's up here to defend me if it gets to. Thank you. Thank you. There. I'll move along. Actually, real quick, anyone know what a Volvo 1800 is? All right. I have a 1972 Volvo 1800 on blocks. It's in my garage, though. It's not in my yard, so it's not quite as redneck. Got a big hole on the floorboard. And it's the sweetest car I was restoring. So anyway, two things to accomplish today and what's becoming a shorter amount of time. One, I'm going to make the case of trusted computing, hopefully. Or at least I'll try to make the case of why there's good in this whole world of evil that people seem to see on it. I'll also demonstrate TPM running on this MacBook Pro right here, and we'll release some code, and it'll be all wonderful. Sprinkle in some good arguments, some beer, et cetera. Here's my anecdotal history of what we've accomplished in the last 40 years of InfoSec. It's not complicated. We've been solving problems, and we've been doing a reasonable job at it, but the problem keeps getting more complicated. How many people in here review code for a living? Handful of people. Got a few people who review code. Is it easy? Is it easy to find bugs? Yeah, it's easy to find bugs. OK. This is not my cell phone. That is ringing. Hello? Oh, Richard? No, this is not Richard. Actually, this is Richard's cell phone. Hold on one second. And there you go. I thought I was going to take the red pill. Anyway, so the problem keeps getting more complex. Reviewing code is hard. Reviewing code in an embedded system that we could have designed 15 years ago is a hard problem. Reviewing code in an enterprise service oriented architecture is currently an impossible problem. We can't write secure device drivers, as was demonstrated by who was Johnny Cash and David Maynard or Black Hat, but let alone at an enterprise level understand what security looks like in these massively complex systems. But yet, that's the buzzword. Go buy computer world or go buy some current contemporary magazine, and this is what we're talking about. We're talking about solving big enterprise security problems. We don't have our hands on the stuff that's 15 years old. So we have a sustainable, profitable industry where we're chasing an impossible dream. This is fantastic. That means we'll all get paid very well. Now, while that's all well and good, it's not actually making anything better. These lines should, at some point, intersect or at least get closer, but they're not really. This is founded in data. I have thousands of data points to back up these two lines if you want to see it later, so. Infosec trends, defense in depth. So the core problem is currently unsolvable. We can't build provably secure systems.   Let's go ahead and we'll slap on firewalls and IDSs and IPSs and execution control mechanisms and all kinds of stuff and hope that we always stay in front of the Wiley hacker.  Wrong, okay? So with phrases like defense in depth, we sound like we're being responsible. Sure, it's the best practice. It's what we got going today. This is the best idea we got, but we need to think about how we're gonna solve these core problems that we're facing in Infosec. Things like, if you access the system directly, you win, okay? Physical access to a system with a backtrack boot disk wins the day, period, right? There are very few situations where that doesn't get you everything you need.  If you can touch the device, poof, there you go. What else is there? And then transactions are trusted at a network level. End-to-end device-to-device security only really exists in controlled and highly, well, controlled, I couldn't think of another word, failed miserably, highly controlled environments. So this is kind of the situation today. I'm being really cynical today, I apologize, but this is the third time I've talked about this in like a week, so I'm kind of down on it. How do we get here? It's a paper from 1971. Butler Lampson, he wrote a paper called Protection. He actually wrote a lot of papers around this period. I'll give you a couple seconds to read through this. Can you read it in the back? Nods, good. So, you know, is this any less true today? Is this any less true of what we're trying to do with System Stay, be it your cell phone or be it your enterprise web server or your SOA gateway? This is the same damn problem, right? His paper goes on to describe in a nutshell, multi-level security, MLS, basically object-level separation enforced by the kernel, keeping things really secure and, you know, the idea is you can keep multiple classifications of data away from each other in a military environment, but in general, you can keep the good data from the bad data, the need for hardware security to enforce this data separation and this object-based access control. 1971, okay? 2006, for reference, in case your calendar broke, we haven't gotten real far. Hey, it's a blank slide. No, it's PowerPoint foo. Ha, ha, ha, this is all as good as it's gonna get, folks. I'll give you a few minutes to read these quotes. All right, any guesses when this was written? Yesterday. Yesterday, ha, ha, another guess. 70, someone had saw the talk, 1972, actually. 68, right, it was a long time ago, again. This was from a computer security technology planning study, October 1972, published by the Air Force. Okay, hey, smells like the same thing we're doing today. Right, if you go through this paper and you redact all the specific systems and networks and random network topologies that I've never heard of, it's exactly the same problem. Wow, we've done a fantastic job in building this industry. All right, so, I'm not gonna be employed by the end of this. The road is littered with corpses. MLS, people have been searching for MLS trying to do this for years. Turns out it's really hard, right? We try to do provable, secure operating systems with formal methods and all kinds of stuff and that hurts. It hurts a lot, okay? In complex operating systems, when you try to build one, the formal methods and everything go out the window the moment the fingers touch the keyboard. Soon as a developer and a human gets involved, it's no longer provably secured or reasonable scale. I hate to say it, but we're not arming our developers the best that we could. It's like going off into the streets in some inner city and having a Nerf gun and walking up to people and smacking them on the head and picking a fight. It's not the greatest idea, but that's about what our developers are armed like these days. They don't learn security when they're in college. They might be able to go to a conference and learn how to audit code and maybe learn how to write some good code. That's not a pervasive thing. There's not armies of millions of developers out there who can write uber secure code. This is a problem. This is something that academics are have to address and they're getting better, but operating systems are complicated. Software developers don't have the tools, don't have the knowledge, don't have the time to write secure code. So the best you can do in that situation is layer on other protection mechanisms that developers aren't involved with like firewalls and execution protection like what's the thing, GRSEC, no, the Amy Nicks. Stack guard, thank you. All right, trucking right along because my memory is failing me. All right, fast forward 2000. DRM emerges on the scene. Woohoo, man, everyone was making money. It was 1999 and everybody was getting rich and then it crashed. DRM stayed around those, turns out. Content was king. AOL Time Warner was going to be the biggest, baddest corporation in the world. Didn't work out so well. DRM though is a key part of how the content evolution, revolution kind of came about. Content providers had a mode where they were used to selling their stuff and getting money for it and as much as Napster and crew were allowing you to download it for free, there had to be a sustaining business model that was developed and digital rights management fit it pretty well. Microsoft even has DRM like capability in office now where you can control where files get sent. It's not perfect, right? Like DVD John, he proved that DVD encryption not perfect. Not rocket science, there was a static key. You get the key, you can rip down DVDs. How many people have ripped DVDs on a PC? It sucks, doesn't it? It really hurts. How many people have ripped DVDs on a Mac? Is it easy? Yeah. Handbrake, baby. There's a great program out there called Handbrake. You hit one button. I was offended when I tried to do it on a PC how bad it was. Like you download 15 different little codecs and widgets and then nothing works together. Blue screens of death that I hadn't seen in forever pop it into my Mac when I was like, oh, there it is, oh, and I have two cores so I can do anything else while we're doing this too because I'm badass. I might not be a Mac fan, but I probably am. So DRM can be subverted. If I really interest it in overcoming the copy protection mechanisms in an office document, I'm gonna just type it into another document, right?  If I wanna take an MP3 or an AAC file that is protected by DRM, I'm just gonna transcode it in MP3, right? It's not rocket science. There's nothing stopping me from doing this. DRM's gonna keep legitimate people legitimate. So we all hate it, right? It's all evil, lose control of my content, blah, blah, blah, blah, blah. Guess what? It's cool. Go ask any college student. Apparently iPods are cooler than beer. This is not the college I went to. I don't know where they took this question from. But anyway, it's all just mind numbing to me. So ultimately, there's some transitivity here, so let's follow the path. iPod, one of the big things that made iPod successful is the existence of the iTunes Music Store. iTunes Music Store could exist because there's a DRM mechanism that Apple came up with that was tenable to the content provider so the content providers could put content on iTunes Music Store. Apple could sell it for a buck. You could buy it. You could get the Britney Spears song you haven't heard in 15 years and download it to your iPod and no one had to know because you didn't even have to go into a store. It's like buying porn, you know?  I buy porn and Britney Spears albums online. February 2006, one billion songs sold on the iTunes Music Store. Now, Budweiser, they sell a lot of beer. One billion songs sold on that thing, that's actually a lot of songs that officially probably puts them in the realm of cool. So, transitivity, Apple made DRM cool. Nobody even realized it. It was sexy, it was useful, it was something the users wanted and they put up with it, you know? If you had an argument on the face of it of, hey, it violates your privacy and whatever, people would probably get upset about it. When you say, hey, but it's a dollar, oh, your eyes get real big and they just kind of wander off into space. Like, ooh, a dollar. So, it, it, it, it, okay, trusted hardware. What does this have to do with Apple? So, Apple's doing the same thing with trusted hardware. I hate to tell you this, but they're gonna, they're gonna, they're gonna have the same effect. MacBook Pro runs on an Intel, okay? Apple, six, seven years ago, decided they're gonna get away from allowing people to sell cloned Apple products and so they got another, they got Stranglehold back on their, on their hardware platform again and the models worked out well for them. Apple's growing, you know, their stock's growing great, they're making a lot of money. IBM relationship isn't working out so well, so they moved to Intel and Apple wants to maintain this kind of, not Stranglehold, but certainly good, strong grip on the hardware market around their software. Knowing, though, that they're walking into the x86 market, which how many people in the room own an x86-based PC? All right, good. I'm just so clear. I thought there might be a few of us. You know, that's a bit of a threat because OS X is actually kind of cool. I mean, all things aside, like it's a Unix that runs Word, all right? So you can go own a box and write a letter to your mom and fax it all at the same time and you don't have to use open office and play around with print drivers. It all just freaking works, fantastic. So when they made the switch, you know, there were certain bits of proprietary things they wanted to protect. I need to caveat with this by saying, this is my crystal ball. I've shaken it up, I've looked into it and this is what it looks like to me. I don't have any inside information from Apple. This is what I've read on the net and I've been able to synthesize based on looking at these machines. But what they want to do is keep this grip on this hardware. So one thing that was really interesting when they made the migration is they have, I don't know, 20 years of legacy PowerPC code, actually, I guess 10, 10 years of legacy PowerPC code and they want to be able to run that on the X86 platform.  So I think they actually acquired a company, they've named the product Rosetta and it does real-time translations of PPC op codes to X86 op codes. Neat, this is their differentiator. This allows them to seamless transition to the Intel platform. This is the little bit of thing that they don't want running on every PC so that people just don't start running OS 10. So what they do is they put a TPM in this thing and then when Rosetta instantiates itself, it checks to see, hey, is this really a MacBook? And if it is, okay, it'll run. If it doesn't, you can't run your PowerPC stuff. Pretty neat. There's a Russian hacker by the name of Maxis who repeatedly bypassed this protection.  I challenge you to go find it right now at Google. I'll give you 10 minutes. I'll give you a t-shirt if you can find me a Maxis patch. They're really hard to find right now. They're really hard to find. And all he was really doing though was going into the binary and sniping out the calls that made the call to TPM and just said, yep, everything's fine. And the thing would start. Software. So the problem was, clearly there's architectural problem there. It was still subvertable by software, but there's long-term solutions that allow, and I'll get into it in a minute, that would actually make that very difficult and not impossible to bypass. So backing up a step. I used an acronym on the previous page that I didn't explain, which in consulting, foo is bad, I'm not having a good logical step. So backing up a step, because I didn't feel like rewriting the slide. Trusted computing group used to be the TCPA. This is an industry group. It's not the ITF. This is not like an open forum that you can just go to Zurich and hang out for a week and talk about the direction this thing is going. You have to buy your way into this thing. They're setting up standards for trusted computing systems and architectures. Used to be solely focused on the development of standards around the trusted computing module, a chip that gets embedded on the motherboard. Now they branched out. They realized just building the chip isn't gonna make anything happen. So what we need to do is focus on, hey, let's talk about infrastructure, mobile devices, PC clients, servers, trusted network connects, storage, software stack, how you access this thing. That's kind of important. And tie it all together. So there's all these documents and there's all these specifications that you can get to try to help you build these systems. That's what the trusted computing group is. If you read their charter and no point doesn't say be evil, be the counterpoint to Google. Don't be evil, be evil. Ha ha, that was funny in my head. So anyway, thank you, thank you. Try to be evil, I'm done, all right. So it strikes me that people think this is inherently evil. And I think the ultimate anecdote for that is the really angry doll on the Simpsons is trying to kill Homer and the guy comes over and is like, oh, you have it set to evil, click. And oh, it serves him food and everything's fine. This thing doesn't have that property one way or the other, all right. It's gonna be what we make of it. So let's talk about privacy for a minute. First of all, I need to tell you up front, full disclosure. I have fully bought into the church of McNeely that says you have no privacy, get over it, okay. McNeely said that many moons ago at some Sun event and I believe him to be fully correct. I know other people in this audience disagree with me vehemently and that's cool. So let's talk about privacy a little bit. First of all, previous versions of the TCG or the TPM spec actually were pretty bad when it came to privacy stuff and would allow for the content providers to really grab hold of your machine and shake it vigorously without allowing you to do anything. And there was a lot of pushback, understandably. So there were also a lot of pushback to things. Remember the Intel serial number issue? You know, when they put serial numbers on the chips. You know, there was no end user benefit there. That wasn't sexy and cool, right? You know, again, DRM, iPod, sexy, cool, serial number on the Pentium profit. There was nothing in the middle, right? It just, it was bad. So the new specification allows for a couple of things. One, the owner controls personalization. Note, owner, not administrator, not the guy in front of the computer, but the owner, okay? In an enterprise, when you're using a laptop given to you by the company that you work for, you have no expectation of privacy on it, period. I'm sorry, I know that there's laws that allow workplace privacy and things like that. But by and large, you should not assume that anything you do in that box is subject to your own little private whims. It can all be controlled and monitored by your employer. So the owner in that case is probably the company. When you buy your own laptop and take it home, you're the owner. You can do anything you want with it, all right? You can take over the chip, you can turn it off, you can turn it on, you can reset it, you can do anything you want to. The private personalization information is never exposed and the keys are encrypted. I mean, I'll get into all this kind of nonsense. In a nutshell, there are keys that can be bound to the TPM and there are keys that you can export off the TPM. The original spec just had keys that were bound to it, which is pretty evil because then if your box dies, all the data that was encrypted with that chip is gone. On the flip side, nothing really got ever made with that particular specification so you don't need to worry about it much. Anyway, that was a rambling, horrible slide. I'm gonna shoot it. Trusted platform module.  At a high level, they got three things they can do. One, assured cryptographic operations. When I say assured, it means someone looked at their implementation and said, yeah, this thing's okay. Not like it's Uber, cool or whatever. It's just gonna do the same thing every time. You can't change it, right? You can't download a new library version and break it. It's just gonna do RSA correctly every time. It serves as a trusted key store. It's on a little chip. It's inside the chip without a lot of high-end gear. You're not gonna be able to extract it. It'll also make an integrity statement. It's basically say, I'm okay. Everything's A-okay or at least it's not okay but it'll cryptographically sign those messages and say that it's not okay. The TPM on its own doesn't do anything. It sits there. When you move the box, it's gonna hang out. It doesn't set the evil flag. Doesn't do IP over avian carrier. All it does is sit there. I boot this Mac running Linux right now. TPM wasn't even activated. Didn't get in the way of anything. Higher level systems must use the TPM to do something, right? They can't just expect like it's gonna intermediate. It again, it is not magical. There's no magical property about this. Magic's not real. That's what my son says to me. I'm eight years old, sorry. How'd you do it? I said it's magic. Magic's not real. He's disenfranchised at eight already. It's great. The TPM spec says the user must have the ability to turn off the turn of the TPM chip that's off O F F. The TPM chip, that means the user always has control of the device. Again though, if you have software that needs it, that means the software might not work. Okay, there's a trade off here. Who in the what now? Like the operating system, like particularly. So let's talk about that. There's a lot more but I've paid some hecklers in the room, particularly ones that look like pirates and truly, there may be things that you wanna use that if you don't want them to access the TPM in your system, they're not gonna work. Okay, now here's the thing. One user isn't important. Same thing I tell people when I talk about wireless security. Nobody cares about you as an individual. They care about you as a group of people. They care about getting 100 million credit card numbers from a VA laptop. They don't care about getting one credit card number. You find the identity theft that's sitting around sniffing someone's home network looking for credit card information. I'll show you the dumbest man in the world. All right, so there's market pressures involved though with massive amounts of people rebelling against something. So if your operating system doesn't boot because it requires some piece of trusted hardware that nobody wants to use, the market's going to adapt.  Okay, or maybe the law will get involved in EFF or ACLU or somebody will sue to make that change, okay? This is a cultural issue, right? And this is the evil side. And clearly that's a battle that has to be fought. I'm not arguing that. I'm not arguing that at all. We're going to fight that battle. And there'll be people up here talking next year about the evils of TPM and some legal battle that's going on or something they're doing with some vendor. Fantastic, more power to them. You know what? There's a lot of good. Remember that graph I showed? Two lines, same slope, not making any progress. Well, let's focus on that part and assume the cultural bits because we all like to moan and groan and complain about the cultural bits. That problem will work itself out. Let's talk about the technology. So, to you, the pirate. It was a very piratey response. I think if pirates stood at the bottom of the ship of it, they probably got blown off with a cannon. Here's the inside of a TPM chip in swank little PowerPoint rounded bits. Going around the horn, you've got IO in the middle, NVRAM platform configuration registers, the PCRs. This is basically a set of information that can uniquely identify your system. It's going to have manufacturer information, serial numbers, peripheral information. This can be used to basically form a hash that uniquely identifies your system in a given state. Again, good and evil. We can all think about ways this can be used for good and bad. Adversation identity key. This is basically the key that's used to identify and authenticate the chip to off-chip entities. So if the chip needs to talk to the rest of the operating system or talk to something on the network, this is the key that gets involved. Program code. This is where it does programming stuff. That was very descriptive. RNG, it's somewhere between a really good RNG and a PRNG. Note, it won't give you the same answer every time, thanks dev random, but it's not necessarily 100% great. SHA-1 engine. Yes, we can debate how good SHA-1 is, but come on now. Key generation, because it does need to generate keys on its own for internal and external use. RSA, state management. This is, is it turned on, is it turned off? That kind of thing. And the exact engine basically executes the program code. That's your kind of processor. So here's how you interact with it. Looks a lot like a smart card. So it's told the other day that there's a reason for that. If you look at the chip model numbers for some of these vendors, there are precisely one model number off or just a letter modifier from the smart card chip from the same manufacturer. So for those that do smart card work, this looks very, it's command response.  There's an application, it makes a library or socket call. This particular datagram, this is the startup datagram.  The first line is the type of datagram. The second line is the size. The third is a specific command, in this case start. And the fourth is a modifier. 01 is a start, it's a fresh start, gets the system up and running from the get go. Note, when a TPM chip comes online, there's two things that happen, or two things that need to happen. The first is a knit, and that's a device specific thing. That's basically when that powers it on. Click, turns on the switch. The second is a startup when you have to send it this thing. All the tools I found under Linux, pre-assume the startup command had been given. So I'm running all these programs, none of the programs are working. They're all cratering with errors like, chip not activated, like, oh, this isn't good.  This is about, I don't know, four days before I'm flying out here. So I'm really not happy at this point. And then I discover, oh, I haven't turned it on yet. So I do the startup and everything starts working magically. So I'll do a demo here in a minute of how that doesn't work. High-level breakdown of TPM commands, administration stuff, opt-in ownership, key management crypto, you can all read. Probably what's most interesting here is the crypto stuff. Bind, I'm a little imprecise here. When you bind, you're encrypting a chunk of information, okay? What you can do is use either these exportable keys or non-exportable keys. Non-exportable keys, if you bind something with it, you're just encrypting it with a key that you could save off to software. So it's not really that secure. If you encrypt something with a non-exportable key, well, now you've bound it specifically to that TPM chip. But God bless you if that TPM chip goes away because cracking RSA is still kind of a hard problem and you may not be able to do it today. You can sign things, no shock. Seal, this is where you're binding, but you're also hashing it in with a PCR data. So this is where you have the data that not just uniquely identifies your computer, but then you use a specific key, you squish it all together, and now you've got a sealed thing, and then you can also sign that if you want to. So this is where you can really get interesting things where you bind specific pieces of information actually to the chip that runs on your device. Upgrades, recession management, et cetera, et cetera. So all Intel-based Macs have these TPMs. So at least I surmised when I started doing this. One night I actually flipped out because I hadn't yet written codes successfully to access it and I flipped and spent the entire night just proving to myself there was a TPM in there and discovered the guts of the internals of the advanced controller and power interface or whatever ACPI and dumped all the crap off the motherboard through the ACPI commands and actually discovered it. It was there, I went and had a few beers, I was very excited. Never fear, we've got some code to examine it because there's no interface from Apple, okay? I'm not saying this to ding Apple, there just isn't any.  You said, I want to find a Bluetooth device, I'll call the Bluetooth device discovery wizard.  When you're trying to write like actual real Bluetooth software, that may not be the most robust way of doing things, but it worked. Wi-Fi similarly on a Mac, there wasn't really good interface to that, so if you want to do war driving, somebody went and reverse engineered the header file so you could actually compile code that ran against the Apple 802.11 libraries. They're getting better, but Apple's not really in the market to make some of this stuff extensible, that's kind of Microsoft's rant in the world. Anyway, they didn't give any interface for this, so we ended up having to use Linux to make it happen. Hopefully we'll have some Apple code running at some point. Not sure if someone was giggling at me or... Anyway, Ubuntu, how many Ubuntu users? Wow, how many FreeBSD users? If you're near the Ubuntu users, punch them. FreeBSD, just if you haven't heard, is God's operating system. It's the greatest thing ever. I felt really dirty when I used Ubuntu, like I had to go talk to my FreeBSD install disk and I'm sorry, it was only a one night thing. Then I went back and recompiled the kernel and didn't tell him about it. So, there's two ways to access a TPM on a Mac. You can use custom applications and access it through LibTPM. It's a legacy thing written by IBM and it just talks to the TPM chip like any other device. There's this other thing called Trousers open source program. There's a demon called TCSD, basically grabs the device by the face, doesn't let anything else talk to it and if you want to talk to the TPM, you have to do it through that. That's Guido, okay? So, TCSD is Guido and then you do socket calls across to TCSD to access the TPM. In particular, the TPM is the Infineon IFX0101, which is version 1.1B. Here's a quick demo, or what I hope to be a quick demo. It may actually be a complete goat rope. So, here's the top of my scroll buffer. Is that big enough for folks to see? Is contrast all right? It's lousy and, well, it's a terminal. It's courier, come on now. This TPM demo, the green things up here are the default utilities that come with LibTPM. TPM demo, in theory, goes through and does all kinds of cool stuff to the chip to show you that it's working. This is what you get when you don't start the chip up. It just says error code 38, which if you flip through all the documentation in the header files, you eventually realize that it thinks that, oh, it's not turned on. So, there actually was no utility to turn it on, so I had to use my immense C coding foo to write a five-line program called TPM startup. Trust me, if you've ever seen me code, that was actually an adventure, okay? I was debugging something for the hacker arcade at Shmucon and Provere, one of the guys in Kenchota that helps run the capture of the flag, that he was debugging it for me, and he's like, dude, you've declared a function inside a conditional. Like, the function doesn't exist because your conditional didn't match and so the rest of your code doesn't run. I'm like, that's not normal? So, me trying to make this thing and then get the make files all set up, make file.in and .am, my God.  So anyway, we do a TPM startup and you know, you get this incredibly verbose message that says it's been successfully started and now we'll attempt fate and see if it was true.  Demos are great when all they show is hex, right? So a few, some applause. This is actually where Caesar's Challenge is gonna be. If anyone wants to take that. Let's see, scrolling up to the top. All we're doing is basically getting the capabilities, information, you know, what can this chip do? It's a lot of hex, I'm not gonna dive through it. There's a few interesting bits. One, we're getting PCR registers here. These PCR05, PCR06, PCR07. These are different registers that in theory could contain specific information or hashing information about configuration on my machine. Serial numbers, manufacturers, that kind of thing. Right now, what's interesting is by default there's actually nothing in them. We scroll down and at some point they start turning into Fs. So we get the higher level PCR registers. There's nothing there. Now we get all the way down to the bottom and there's two big blobs of data. These are the public keys that uniquely identify this TPM, okay? These are kind of secret, kind of not public keys. They're not something you should really let off your box but if you're really crazy you can take a picture of this and then try to own my TPM on my machine. More power to you again. Does anyone manage to Google and find Maxis' patches? See, that's just not cool. I was hoping somebody would have. Because largely I haven't found them. I'm very curious too. Anyway, these are the keys that uniquely identify my system and they'll export it. And so if I want to interact with it, if I want to assign things, put new keys on there, export keys, this is the key that I have to use to do that. I can reset the whole system and make a generated new key but that's going to screw up previous transactions that I already had. So anyway, that's the demo, all right? There's a few things that were interesting about getting this whole thing working and we actually have code now that'll run and do this automatically. First of all, this thing doesn't use a BIOS. I think a lot of you probably already know that. It uses EFI. EFI is a pretty neat little boot loading thingamabob but it's a real pain in the butt to build live CDs and make things work on it. They made this thing called Boot Camp that emulates a BIOS. I didn't want to actually touch my hard drive. I wanted to boot something to an external USB disk. So after some wrestling, I actually managed to take the live CD of Ubuntu that booted, put it onto a USB disk, upgrade it, get a new kernel on it, make all the TPM stuff work, get the configuration right, and then I tried to burn a live CD. I made about 40 coasters and decided at that point I was done and all I did was upload a gigantic tar ball up onto the website. So there's like a 680 meg tar ball which is basically a file system. Don't think more glamorous than that.  And actually it's kind of nice just to have an external Mac disk or an external, you know, Hoosy What's at Linux disk to be able to boot on your power book. So I saved you all the hassle and figured out how to do that. You can just download it and do it.  Trusted network connects. So network access control, network access protection. These are neat little buzzwords these days. You know, we're trying to protect access to our enterprise networks more and more rather than solving the entire, you know, MLS signed object trusted boot problem all at one shot. Something that TCG is doing is it has this thing called trusted network connect. The idea here is that it's a formal and normal, it's a specification to control how systems connect to the network. For all intents and purposes, it's 802.1X back ended into a TPM chip. Okay, it's doing authentication of the device with a device specific key. There's a key, comes out the TPM, gets, goes through the authentication process. Now the device, not the user, the device is authenticated on the network. You can do all the typical quarantine and patching and everything that you wanna do under the guise of TNC. Juniper has a solution that's TNC compliant. Cisco has a competing solution that is not TNC compliant. They've got their own thing. Microsoft has their own way of doing it. No one's bought into the church of TNC really heavily yet, but there are options you can actually go and deploy them if you desire. Here's a really bad diagram I lifted from a website that just has arrows and boxes that describes the TNC. Anyway, phenomenally useful slide. Other capabilities. So this is, now we've talked about the low level bits, like hey, you can encrypt data, you can sign data. That's awesome, we could do that anyway. What else can you do? Well, higher level issues, data at rest security, right? You wanna secure a hard drive or something like that. Vista has the ability to use TPM for key storage and an e-cure container. Oh my God, I didn't copy edit this at all. This is thing called BitLocker. This is kind of a funny one. How many people actually use encrypted drives and encrypted volumes for what they do? That's not bad. In the general population, the number of hands that go up are far fewer. And it strikes me that at an enterprise level, it's a real pain in the butt to do that. And after this VA laptop thing got stolen, first of all, every laptop on every desk and every corporation is a liability to that corporation.  It's a factor of life, you know? There's just stuff on everyone's hard drives that shouldn't leave the organization. And I don't know how CIOs sleep at night knowing that they've got people completely untrained in InfoSec and OpSec running around with these little laptops, like doot, doot, doot, doot, you know? Just oh, I left it in my car and the car door was open, now it's gone. Oops, 40 million social security numbers go away.  So I was like, oh, this all could have been solved with drive encryption. All right, give me a break. It's not that easy.  Maybe a few people do, but it's certainly not the norm. There aren't a lot of tools out there to do that. BitLocker technology-wise is really cool, okay? But it's not really, you know, there's no handle on how do you operate, how do you maintain this in the enterprise. Microsoft's trying to get that together. But it's not, you know, no one's really deployed this yet.  Nobody knows how that's gonna work. So, box, exit stage left. Crypto API, no confusion if an algorithm is implemented correctly anymore because it's all in the hardware and assuming you trust the hardware then everything's okay. Note, there's an open SSL library available on the trousers website that's been compiled against the TPM so you can actually download or you can basically use open SSL back into the TPM for the crypto capabilities and key storage. Kinda cool. Remote attestation. This is where you can tell a remote device hey I'm okay or hey I'm not okay. Trusted boot. This is really the kick in the pants, right? I got a TPM, I got a secure boot loader. Trusted, provably secured, a little bit secode. Now I can load a signed kernel. Signed does not mean secure, but it means it's at least the kernel I intended to load, right? And then I can load signed drivers, signed applications and at least I know what I meant to do happened, okay? Wasn't a root kit, wasn't something else. Everything that I intended to have happen happened.  This is a really neat capability. We can't really do this easily today. I mean you can try, but this will, you know Microsoft and Linux and these other vendors are all working toward a solution that will allow us to do this. Hey, can you imagine me able to boot your box and know definitively? At least right now I know there's no root kits running without having any other security software running. No antivirus, no antispyware, nothing. It's kind of neat. It's a neat little future that we can think about.  Types of attestation. I only got five minutes so I gotta drop the hammer here. Attestation by the TPM. This basically says I'm a TPM and I'm here. Nothing more complicated. Attestation to the platform. This basically says I'm here and I'm okay. You can trust me to tell you things. Attestation of the platform is this is where you say and the entire operating system is screwed up. Okay. So if you've gone through number one and number two you can at least trust the answer of is the whole operating system okay? They'll say no. God, no. You're owed. You got that Sony root kit, man. Rocks. Oh yeah, I got a woo for the Sony root kit up front. That side. You work for Sony, sir? Oh no. He's got the RSA barcode shirt on. That's pretty hot. Talk to me later. An authentication of the platform. This is device authentication, you know, hey, nothing, it's not rocket science. I mean, I hope I bored you in the last 20 minutes because this is not rocket science, right? Nor is it evil. But that's pretty cool. Like this is really neat stuff to be able to do and say hey, this is actually grounded in this little hardware thing that's really hard to subvert, okay?  We can actually have a pretty reasonable proof that this thing is doing what it's supposed to do. Again, we're not solving the assurance problem. We're solving the integrity problem here. Again, I haven't said that yet, but I said it like you were all internalizing that whole statement. So first the bad opportunities are bound for loss of control of context or any computer, yeah, okay, we get it. Failed hardware is an issue. Users aren't used to thinking about key management, right? Like how many people back up their SSH keys? How many people wish they had backed up their SSH keys? There you go. And we're all smart computer security folks. When my mom calls me up and says, hey, I have to back up my TPM keys and I'm not sure how to do it, it's a bad day. It's gonna be really bad day. Operating system vendors may get territorial. I mean, honest to God, like it was pointed out by the pirate. Windows General Advantage could decide, hey, you've got Mozilla, I don't like Mozilla.  I'm not saying Microsoft's gonna do that, but the potential exists. This is where technology ends and legal and market pressures begin, okay? Let's continue to make that distinction. I'm talking about the technology and the good that can become of it. The bad clearly, bad things can become of it. That will be solved differently. If you try to make technology solve the problem of not having bad things happen, you've lost, okay?  People are just gonna come steal the computer, okay? You can't solve all these problems with technology. You can't solve privacy all the way with technology. There's market and legal issues that are gonna step in. So you just kind of need to take the red pill and accept it. The good, trusted boot can make a big dent in controlling malicious code in the enterprise. Integrity of your boot process is a really cool thing. Trusted network access, we're already, the train's already left the station. We're doing 1x, we're doing knack, nap, all that kind of stuff. Now we can tighten the hardware and even more assurance of the device that's connected to the network. We have the ability to protect mobile media and other data at rest situations. The ugly, we're all distrustful, angry, drunken people and this represents a big shift for our world. It really does. It changes everything we know about InfoSec for the last 40 years. This defense and depth idea changes because now we start talking about kind of this bottom up provable security at least at a lower level. And it really, when you think and you look at MLS and you look at all these signed objects right around, this is not how we think about systems. This is not how we build systems today and it really is gonna cause us to have to change how we look at this stuff. Vista has a TPM support, but you have to have a 1.2 version TPM which there aren't a lot of them out there. This one's 1.1, most of the ones in the ThinkPads are out there, 1.1 as well. The Vista TPM developer support largely consists of documents that have function calls and then documentation to be written later underneath the function call. So there's really not a lot there. Where trust and computing is going, many systems have TPMs, not a shock, huge capability, and rants. Couple other points I wanna make before I end this thing. One, Shmucon 3. How many people went to Shmucon? Woo! All right, well I hope that got the attention in another room. So someone actually said, I've been to all three Shmucons, they were all great. There's actually only been two. That guy had a really good time in one of them apparently. Shmucon 3 will be March 23rd to 25th, 2007. People may ask why so late if you didn't in January last year. It's because I didn't get to go see my folks over Christmas time because me and my wife and everybody else were getting ready for Shmucon. So I'm being selfish with my family and we're gonna go see our folks and then we're gonna have Shmucon in March. Same place, Mormon Park, Marriott, very nice venue, slight change in structure, the highlights. We're gonna do 20 minute sessions in the afternoon on Friday, which would be kinda cool. Kinda turbo talky, but it's just gonna be one big track everybody's gonna be in it. And then we're gonna do, how many people remember the network they used to build? It was a network interop. Network interop? Interop, yeah, the big interop network and they got all these hot shots and vendors together and they plugged a bunch of stuff in, they made the network and they ran and then it became more commercial and then it got relegated to the labs and then just kinda went away. What we're gonna try to do is the same type of thing for Shmucon. We're gonna get in vendors, we're gonna get in smart people, we're gonna get in people that wanna learn and we're gonna build an enterprise class security network to run the con or else we're just gonna use twisted pair and lay it on the floor if it doesn't all work out. So one guy will be tagged with bringing like 4,000 feet of cable and crimpers and the rest of us will go build a secure network. So anyway, we hope to have some fun with that. So that's kind of the few days beforehand. We're still gonna have contest, hacker arcade, all that kind of stuff. CFP will be out next week. Tickets on sale next month. One last item. I know I'm gonna get bum rushed here off the stage. We were given the opportunity to mentor four projects under the Google Summer of Code. I wanted to mention them really quick. If you go to code.google.com slash SOC, you'll learn more about Summer of Code. I have time to explain it. Four projects. First one's Firekeeper. This is a browser level intrusion detection. Looking for cross site scripting, fishing sites, all that kind of stuff from the browser side and blocking them from causing anything bad to you. It's pretty neat. Firekeeper.mozdev.org for more information on that. GPG Grease Monkey. Client side mail encryption now via a Firefox extension. We're originally trying to do it by Grease Monkey, which is basically JavaScript, rewriting the pages on the fly to do neat stuff. The problem with JavaScript is there's this little security thing that doesn't allow you to access like local binaries on the machine, like say GPG. So the student came to me one day and said, I think I'm gonna have to write GPG in JavaScript. Is that okay? Like, no, no. I don't think that's a good idea. Like, I don't wanna see you on the news at the top of a bell tower. Ah! Des, des, eh, yes. Ah! So rather than do that, we went to a Firefox extension which doesn't have the security concerns. We currently have an implementation for Gmail and Yahoo. There's the SVN information if you wanna go get this version stuff. This will all be on my website later. This is a screenshot that's so tiny that you have no choice but to believe that it works. There are little GPG encrypt and sign things there. It's kind of funny. Johnny Long was given his hack in Hollywood talk when he had all these Gmail screens that had all this extra functionality and thought he did it all with the grease monkey. So when we started this project, me, the student asked, he said, Johnny, hey, how'd you do that? And he says, oh, I just photoshopped that. Oh, dope. So, yeah, we've now fixed that problem. Two other things. Online Rabel table lookup. Focus largely on increasing the speed of how fast you can look up hashes. There's a DNS interface. So if you're actually at a site where they can send out hashes in the clear and get passwords in the clear on port 53, you probably have no security policy problems whatsoever. Anyway, we've got basic search capabilities completed, et cetera. Open Security Framework. Pub's running this one. It's basically a framework to fly network security analysis. When I asked him for a synopsis, he says, well, you know, it's got a master client slave architecture. That was what he had. Like, what does it do?  So there you go. Anyway, I'm out of time. Go to Shmucon. If you have questions, come track me now outside. Thanks, all.