Welcome to my talk on the trusted computing platform Alliance, the motherboard of all big brothers. I'm Lucky Green. Some of you may have seen some talks here before in years past. This one will be a somewhat unusual talk. The reason why it will be unusual is because you will hear a tale of epic proportions. You will hear about conspiracies and deceit. You will hear details about conspiracies that some certainly would say are conspiracies that have been going on in some cases for as much as seven years. I'm quite glad that I've been scheduled after this very interesting talk by a scholar of attorneys which had certainly addressed some of the details of the DMCA. Because this talk too will, by necessity, even though it's mostly a technical talk, have to address some of the issues that DMCA is raising probably to most of us that are interested in how our equipment works. Some of you may have heard sense of Microsoft's Palladium initiative, which is very much related to the initiatives of the trusted computing platform Alliance. I won't talk about Palladium specifically, except that Palladium is really a subsection of the TCPA with some slight modifications. The Palladium effort grew out of the TCPA effort. Microsoft has made some minor changes to the underlying architecture, but many of the components and most importantly all the conclusions remain intact. So, first of all, what is the TCPA and what are its business objectives? The TCPA's business objectives are fairly straightforward. Its members wish to prevent the use of unlicensed software, such as say copies of Microsoft's licensing fee or that could be copies of an operating system, but naturally it also will be copies of digital content. A key component of TCPA is to mandate and make stick. From a technical perspective, not just from the legal perspective that the DMCA allows you to make copy protection stick. From a technical perspective, make it stick that you will not be able to rip CDs, you will not be able to create divixes. It will plug the analog hole and I will later get into what the analog hole is all about and why Senator Hollings is very much interested in the analog hole. It will, which is probably the most insidious aspect of the TCPA, enable a truly Aurelian information flow control scheme that is so far unthinkable because the technology is until the TCPA simply hasn't existed. Lastly, perhaps not lastly, an additional objective of the TCPA is to grow the market for the PCs. Here's why. One of the TCPA's founding members is Intel Corporation. Intel, as most of you know, makes most a fair chunk of its money from PC microprocessors. Intel owns most of the market of the PC microprocessor. Really AMD's only left as a competitor and they're not a very big one from Intel's perspective. So how does Intel grow the company? As far as Intel is concerned, the way to grow the company is by growing the market for PCs. One market niche that has been identified are home entertainment center PCs, such as many folks already have set up their own video servers and MP3 servers at home. It's quite clear that there's a consumer market for such a product. Intel intends to be providing the chips. And then an issue that, of course, can never be forgotten. Whenever you see these large industry initiatives, they cannot be pulled off without government cooperation, or perhaps one should say government collusion. The government too has some objectives they wish to see their operational needs met. That could be the FBI, that could be the Office of Homeland Security, the NSA, and let's not forget about non-U.S. law enforcement agencies, which have needs of their own that are perhaps somewhat different from the needs of those in the U.S. How does TCP accomplish these business objectives? It does so to sum it up in one sentence by preventing the owner of a computer from obtaining root access. That is you. By taking away a root from the owner, and giving a root to third parties, such as those mentioned on the previous slide, and making it stick from a technical perspective, the members of the TCP believe that they can finally do away with all these pesky cracks and hacks and seal numbers and binary patches to MSO.DOL that will make the registration codes go away, and all these other things that they feel are costing them money. How is this accomplished? It's accomplished by adding a whole new mode to either the chipset or the CPU. There will be three levels of access. Privileged access, which is available to TCPA members only, and the clientele. Underprivileged access, which will be available to you. And unprivileged access, which will be available to non-TCPA applications, basically dental code that you simply don't trust. Where is all of this coming from? The trusted computing platform Alliance has a somewhat interesting history. It grew out of a number of efforts, certainly process idea of Intel, big failure, big public failure in 1998, but just because Intel was crucified by the press and at the time by its competitor AMD does not mean that the ideas have gone away. It simply means that the ideas have somewhat changed and the implementation cycles have lengthened. The implementation is still very much in track. The concept of encrypted CPU instruction sets. I first heard about encrypted CPU instruction sets coming out of Intel. I think it was in 1995. At the time, Intel fully intended to roll out encrypted CPU instruction sets as the second phase after the processor ID. When the processor ID went down in flames, Intel decided that perhaps now might not be such a good idea to roll out encrypted instruction sets. Or suffer the same fate. So encrypted instruction sets, again, have been put in the back burner. They have not gone away. The international cryptography framework by HP, few people remember, it was a fairly big initiative. And then of course, smart cards on the motherboard, which IBM is working on and a few other initiatives that I don't really want to get into at this point. Who is the TCPA? The TCPA was founded in 1996 by Intel, Microsoft, HP, Compaq and IBM. There are many DRM initiatives out there. Some of them have been founded by the content owners. This is a different initiative. Intel, obviously, Microsoft is the largest operating system and application vendor on the planet. HP, Compaq and IBM, between them own a fair share of certainly the business side of the platform market. And Intel, of course, provides the CPUs to the vast majority of these PCs. So really the TCPA is a form of platform product vendors. Who has since the initial founding members joined the TCPA actively? On the CPU side, we have Intel, advanced micro devices in Motorola. Hands up here who has, for their daily primary computer is using a PC that is not using a CPU by one of these three operating system vendors. One, two, three, four, okay, we have a few. Not very many. The BIOS and chipset vendors, or as they say, the BIOS vendors and some specialized chip vendors, Phoenix slash award, they have merged. AMI, National Summit Conductor, which again, amongst them, accounts to the overwhelming majority of the BIOS market. On the security side, perennial favorites, VeriSign, WaveSystems, RSA Security, Checkpoint, Certicom, Trend, Micro, Semantic, Clipwire, and the Swiss Crypto AG, which is probably best known for the fact that they actually put our NSA traps into their equipment. For many years, one of the sales folks was arrested by the Iranian government, must have been at least 10 years ago for selling the Iranian government NSA spiked equipment. Crypto AG immediately fired the poor guy who was rotting in an Iranian jail, even though he was the best selling salesman of the company, had been so for many years. Not really, it's essentially the European vendor branch of the NSA. On the application side, we have Microsoft, Little Surprise there, and Adobe, Very Little Surprise there. The scholar of case that you heard about just in the presentation earlier, of course, was all about Adobe. Adobe called the FBI to ask the FBI to please pick up scholar of criminal charges. Adobe later on distanced themselves from the activities, but the bottom line is it was Adobe who got it all started. System side, again, you have seen these names, HP, IBM, Dell, Gateway, Fujitsu, Samsung, Toshiba. All the major platform vendors, all the major laptop vendors, except Sony, which is a different story, are arrested later. All in all, the TCP has 170 member companies. I know the font is too small to read. Suffice to say, it's the who's who of the platform market. Alright, how does TCP work? Let's talk about the technology. There are two phases. Let's talk about phase one. In phase one of the TCP, a trusted platform module, or TPM, which was Anderson and his FAQ about the TCP lovingly calls the Fritz chip, after Senator Fritz Hollings, who has currently a bill pending in Congress, that I'll talk about in more detail later. What's the Fritz chip? The Fritz chip is a tamper-resistant chip that will be included on all future motherboards. A little while from now as to how long is unclear, you should see the first such motherboards probably showing up on the store shelves, according to an analyst at Gardner Group that I've discussed this with, about in the first or second quarter of next year. At that time, not all your motherboards will have the chips, but the first motherboards with these chips will start shipping about Q1, Q2, 2003. That's according to the Gardner Group. The chip will be surface mount. It can either be a separate part of the motherboard, or it might be integrated with the existing chipset on the motherboard. It really is up to the chipset manufacturers and the motherboard manufacturers. The chip will be a comic-artier EL evaluated to EL level 3 augmented, which is really the highest security evaluation level you can do for a part at the cost constraints that the manufacturers were under. You can do certainly better. You can get a device, say, one of the boxes from inside, etc., but now we're talking of thousands of dollars. You can't add thousands of dollars to the cost of a motherboard, or you will no longer sell any. The cost of the part realistically has to be down somewhere in the dollar range. What does the TPM do? It has two major areas of functionality. One is measurement, which I like to think of as snooping. And the other one is reporting, which is probably best thought of as snitching. Let's look at the measurement side. On the measurement side, you have the components that you would expect. You have an engine that supports basic cryptographic operations. You have a secure cryptographic key store. As I'm speaking here, I'm using terms such as trusted and secure. They're used in this presentation and by the TCP and its members somewhere differently than most of you probably would and most of its customers would. Trusted here means trusted by Microsoft to prevent you from copying their software and trusted by Disney to prevent you from watching their movies without giving them a dollar. Secure here means inevitably secure from the owner that is secure from you. This secure key store allows the applications that make use of the TPM to securely store keys that the user and the application will necessarily be able to read out. There is the expected key management primitives and there is something that I call the boot process hashing because one of the measurements that the TPM engages in is measuring all the components of the PC boot process. I will show you later as to how this works and what these components are. Let's look at the cryptographic operations. What would you expect? There is built-in support for hashing, Shell One and HMAC. There is a random number generator built into the TPM. Yet again, much to my dismay, just as we saw with the random number generator by Intel, we are only given access to the post widening output. The cryptographers, amongst you, will know that what this means is that you have absolutely no assurance that this random number generator is actually good or in fact is fully deterministic with just a 20-bit seed. You simply have no knowledge and no worth determining the quality of these random numbers. This is not accidental. The common criteria evaluation specifications mandate that the user not be given access to the wall bits or anything pre-widening. Why I leave it to your imagination? The bottom line is that neither you nor anybody else will be able to determine whether this random number generator actually is trying numbers or is spitting out predictable values. You have your expected asymmetric key generation. It's 2048-bit RSA, which is actually one of the few changes that the design has seen in the last few years. It initially was specified a 1024-bit, but Microsoft and Disney apparently felt it and Intel felt it insufficient to protect their connects copies of Snow White, so they moved up to 2448-bit. You have the expected asymmetric key and crypt decrypt and symmetric and crypt decrypt. Initially, the specs called for triple those because AES had not yet been specified, but with AES specified, probably what you will see is the use of AES. Then, as I mentioned earlier, there's a tamper-resistant hash-in key store. All right, let's look at the key management. Am I going too fast? Can you guys hear me? All right. There's a lot of ground to cover and we only have an hour or actually only 45 minutes, so I'm trying to rush through this talk a bit, but there's a lot of information. They've been working on this for a long time and they've thought about it very hard. You may wonder how to actually know about this. I initially found out about it quite a few years ago, but I must confess in public that I spent an entire year sitting on a TCPA working group. I sat in the working group because at the time I believed that this might be a modelist technology to secure what's sitting underneath my operating system. I don't trust the hardware that my OS is running on. I thought that TCPA was the way to give me the assurance that I can trust my hardware. I ultimately realized it was unable to do that and moreover it was able to do other things that I by no means wanted to see done. Learn a few things. And just for the record, all this information is public information. I'm not violating any NDAs. The TPM is at the factory equipped with a TPM unique, which means motherboard unique endorsement key. This is an RSA key that's signed by the TPM manufacturer's key, which in turn is signed by the TCPA master key. It's a key hierarchy that goes back to the TCPA master key. We do not know, I do not know, nobody that I know that's able to talk about it knows who owns this TCPA master key. It would be a marvelous topic to determine. This key is used to determine that the TPM is genuine and it's not just something that pretends to be a TPM on the legal of the keys and therefore allow it to not pay for Microsoft Word. Once the user takes possession of the TPM, the user then generates key pairs, multiple key pairs if they wish, submits those to a CA for certification and the TPM signs this certificate request with the TPM endorsement key that's proving to the CA that the keys were generated by a real TPM which in fact does not have access to the private keys. Let's look at the hashing. I don't know if you can see this graph, but I'll try to run you through it. Let's take a look at a trusted computing platform pre-operating system boot process. This is really just the standard PC platform boot process with some enhancement. In the top left, we have the root of trust. You have to start trusting somewhere from something In the TCPS case, you have to trust the bias boot block. The bias boot block, if the bias boot block is compromised, all bets are off. However, if there are various reasons why it's hard to replace the bias boot block in this case. The bias boot block loads the bias. After the bias, you have the various option arms load for example, your Ethernet cards, your SCSI cards, your option arms might be loaded after the bias is loaded. If you look at the right side, you see in the gray area that's the TPM and it's associated storage area, which by the way is unlimited. The TPM, very similar to what Encypher is doing with the key blobs, the TPM simply A as a triple does encrypts the data and then stores it as an opaque file and disk. Thus, the potential protected storage area behind a TPM is as big as your hard drive. A TPM stores the hash, option arms are being hashed. The hash is loaded, option arms are loaded. Then you load the Digital Rights Management Bootloader, the hash of that is stored, which finally loads the Digital Rights Management Kernel. The Digital Rights Management Kernel is what Microsoft in the Palladium Initiative calls the Nub. I don't know why they call it the Nub. Or Trusted Operating Route. The Trusted Operating Route is essentially, it's very similar to a MicroKernel that gets loaded before your existing kernel, be it Linux or NT, your existing ring zero supervisor, before your existing ring zero supervisor code ever gets loaded, you're already running on top of a DRM MicroKernel. After the DRM MicroKernel loads, it loads the operating system. The TPM against throws the hash. There may be an additional step. When I'm speaking of an operating system load, this is a generic operating system. This is what TCP allows an operating system vendor to implement. Not all operating system vendors will implement all features. This is the sum total of the features that you can put in. What you frequently will find is that either the entire operating system or critical parts of the operating system will be encrypted on disk. What happens is the TPM loads the machine-specific decryption key of the operating system binary, decrypts the operating system encrypted on the drive, so you don't actually know what the operating system does anymore because it's AES encrypted, so there's no more reverse engineering or patching an operating system without permission. The operating system gets decrypted and the AES binary gets decrypted, loaded as usual. In phase one, the decryption of the symmetric decryption is actually taking place outside the TPM. The TPM decrypts, the TPM provides an internal RSA key which decrypts the AES key, but that's not initially done in hardware because it was too expensive, which of course means that there's an avenue for attack in future versions of the TCP of course in the proposed Microsoft Palladium. This would actually be done at the CPU level, thus requiring you to go through some fail-invasive measures to actually get the decryptor. The operating system gets loaded and initially the operating system will load an approved hardware list, which I will just call here an HCL, and the initial serial number of a vocation list, an SRL, you may wonder what the heck is a serial number of a vocation list, I've never heard of that, we'll get to that. The TCP, the trusted computing platform operating system is, are you getting scared yet? Yeah, you should. The trusted computing platform operating system is now in a known initial state. What do we know? We know the BIOS is TCP approved. As far as these approvals are concerned, if you think you can get an approval for your distribution of Linux, your limb distribution, then you're out of your mind. The BIOS is TCP approved and signed, the PCI cards or TCP approved and signed, or at least the expansion realms are. Of course, who would get signatures for the devices? Well, certainly nobody who cannot certify that the DMA channels used by the devices do not enable unapproved access to operating realm, because with DMA, of course, you can just go straight to the operating realm without ever going to the CPU and it's DR and microkernel. Hence, you need to know that the hardware that hence no assurance that you don't use DRM to get at Snow White, no signature for you. You also will know that no kernel of the debugger is loaded because the operating system binary is hashed. You have a hash of all the modules. You know for a fact that there is no way for the user to get at the raw bits. You have an initial list of undesirable applications that you are not allowed to run. That's our serial number of vocationalists. Let's give some examples of TCP or TCP-like operating systems. This is, of course, Microsoft's Palladium. Take a look at the DRM or its patent that will go into some more details as to what this is all about. What didn't make it on the slide, both HP and IBM are coming out or planning to come out and are actively working on TCP-a evaluated versions of Linux that actually will have been subjected to security evaluation. Again, I will talk about these a little bit more later. What does the trusted computing platform operating system initially do? It first starts a secure time counter. There will be no turning back the system clock. Why is that important? Well, if you say a rent, a video for a week, we certainly wouldn't want you to watch this after 10 days. Or if your Microsoft Word license will be for the period of a year, then you certainly should not be able to run it after a year and a half. The operating system then synchronizes against an NDP server. Finally, it goes over the Internet, obtains a new hardware control list and a new serial number of vocationalists. This doesn't have to happen every time the OS boots up. There will be metrics that will allow you to work in an offline mode. You don't have to always be connected. But say if you don't connect for a week, your DVD may no longer play. And if you don't connect for a month, then perhaps your work process will no longer work. The exact time is your DVD. Now, in the pre-application mode, there will be two primary application loader protection modes. The first one is mandatory. In a mandatory mode, the operating system will simply flat out refuse to load any non-TCP approved applications. Or applications that are on the serial number of vocationalists or just otherwise deemed undesirable. There will also be a voluntary mode in which the operating system will load a non-approved application, sending a signal to all running applications that the system has been compromised by its owner to please clean up after itself. As a result, and I actually have a little graph here, a little table of how this works, if you're running in voluntary mode, you can load an unapproved application, but all the applications that are expecting the dealer and microkernel to guard them against the user will then simply shut down their lives out their memory and ask the operating system to clean up after themselves before your application ever gets on the memory. What will the application do if it's been loaded? Well, the application of course verifies the hatches that are stored in the TPM that we stored earlier. It verifies that it in fact is licensed for the particular platform, as I mentioned earlier. Each platform owner will have keys that are specific to the platform, so you will know for a fact that this copy of Office is licensed to this particular motherboard and no other motherboard. It will verify the license duration, say if you have a license that's time-limited, which under that scheme most licenses probably will be, because you can now actually finally make time-limited license stick. It will obtain a first-year number of application lists from the net. It will verify that mandatory applications are running. One example is there are a number of application vendors out there that are nowadays subsidizing the application by means of Spyware, be that Gator or whatever. There's a bunch of them out there. You folks have seen them. But what they found is that there are users out there that will just simply uninstall the Spyware that's running on their PCs and that's getting the benefits of the free software without the drawbacks of the Spyware. Under the scheme, you can guarantee that an application that you deem necessary for the application to run such as Spyware is in fact loaded, operating and unpatched or otherwise disabled. Then the application in some cases will obtain a fresh document or a vacation list from a number of document or vacation servers. I will explain to you what document or vacation servers are again on the later slide. Only at this point the application will actually accept user input or do anything with your documents. Why? What can... Why are the application vendors so keen on it? Well, as I mentioned earlier, there's a revenue enhancement issue. There is a... It allows, at least the belief, it allows them to grow the market. Here we have some good quotes. Bill Gates says, we can think of this about music, but then, as in digitalized management of music, but then we realize that email and documents were far more interesting domains. Why email and documents far more interesting domains? And Stephen Levy wrote in the article that in the Expo about Microsoft's Palladium on Microsoft NBC, he wrote, you could create word documents that could be read only in the next week. So we get to the first quiz. How will the law help the TCPA and its members start for competition? Here's why. The application vendors, such as Microsoft and Bill Gates said so as much in the interview, intend unwrapping all their file formats in digitalized management. Those of you who were here for the previous talk will know the answer. So what's the question then? The question is, what is a federal prosecutor call an application that is compatible with a proprietary DOM-wrapped file format? Any takers? A circumvention device, exactly. It's an illegal infringement device. That's correct. An illegal infringement device. What does it mean if your compatible application is an illegal infringement device? It means that the software author who wrote this application is subject to $500,000 fine and five years in prison, double that for each subsequent offense and for writing a comparable application. That doesn't even require any rules. That law is already in the book. It's called the Digital Millennium Copyright Act. So that leaves software authors with two very simple choices. The moment file formats are wrapped in DRM, you have two choices you cannot create into operable software or you can spend five years in prison. That's assuming that you only have one user. If you have more user that adds another 10 for each additional user, which is not to say that they'll put you away for 100 years, which they probably wouldn't, they will simply come to you and say, well, we can put you away. There's about an 80% chance that we can put you away for a very, very long time. Are you willing to take the chance or will you just simply plead guilty and take the five, six, 10 years that we're offering you? Your attorney will probably tell you, and I'm not an attorney, but I hope there may be some attorneys in the courtroom, in the courtroom. But your attorney will, I believe, and I'll likely will tell you that you're better off to take the deal. And you probably will fill the same way. We talked about measurement. Let's talk about reporting. So we have the snooping. Let's get under the snitching. TPM reporting is about reporting state to challenges. Challenges can be the local operating system. It can be the application. In most cases, though, it will be a remote challenger. A remote challenger is a challenger that requests state via the Internet. Digital content servers, secure time servers, and information authorization servers. Looking at reporting to remote entities, the remote challenger, which could be any of the above entities, can determine that the platform is in an approved state. The owner of the machine does not have privileged access to the CPU. The operating system and application software are fully licensed to that machine with maintenance fees paid. The operating system and applications are completely utterly unpatched and modified because otherwise they have a hash word and check out. And of course only approved applications are loaded if that is of interest to the application vendor or content provider. What features does TCP enable? It enables, first and foremost, to secure an ongoing revenue stream. TCP makes it trivial to enforce annual licensing fees. It allows you to stifle competition, which we've discussed. What else does it allow you to do? It allows you to defeat the GPL. It allows the vendors to enable, the inventors and the courts and the intelligence to enable information and validation. It facilitates intelligence collection and of course it meets the needs of law enforcement and many, many more. We've talked about the first two. Let's talk about the next one. Let's talk about how does the TCP allow an application vendor to defeat the GPL. HP and IBM are developing a TCP compliant version of Linux. Now, a question that has been raised by Ross Anderson, a researcher of UC Cambridge of Cambridge University in the UK was how do they plan on making money of this? After all, the GPL requires that their result is covered by the GPL is just as much open source because they have to give it away for free. The evaluation process, an E3 evaluation process for an operating system requires literally stacks of documents this high. It is a bureaucratic nightmare. It requires many months. If you get away with $500,000 for the process, you get away cheaply. So how do they make money of it? It's simple. Yes, they will not, neither IBM nor HP nor anybody else going through the process will deny that the result is covered by the GPL. They fully will admit it. You will be able to download the source code. You will be able to download. You will be able to compile it. You will be able to patch it. You can't do absolutely anything except run it in trusted mode. Your operating system will do anything. It just won't run in supervisor mode, on which side it does away with some of the utility of the operating system. Why will it not run in supervisor mode? It won't run in supervisor mode because you don't have the right certificate. You will need a motherboard-specific certificate in order for the operating system to access privileged mode on the new motherboards. Well, you don't have that certificate. Even if HP and IBM were to publish their own certificate, it only works on their motherboard. It doesn't do you any good. So, there were some suggested fixes to the GPL. I'll go over a couple of them. The first one is to require a software office to provide whichever services are necessary to enable an application to operate as the user desires. First and foremost, it would kill the GPL. It violates rigid statements, free speech versus free beer principle because it would require the application vendor to create a certificate for each user. They may not be able to do that at any rate. They would have to provide a service to each user. I say the user sends them a key. They would have to send them back a cert. That's no longer permitting free speech. That's providing free beer. Furthermore, the application vendors can't just provide you with a master key because the TPM, of course, does not just secure HP or IBM's version of Linux. It also secures Snow White. If IBM and HP were to provide you with a master key, chances are you would be able to decrypt other digital rights management and encrypted software and thus, that would be the violation of DMCA. Lastly, in many cases, you will have third-party vendors, such as various sign-sign certificates. You can't conceivably mandate that a third-party vendor provide a service that isn't even part of your contract. What did Richard Stallman have to say about this? I talked with him about it. His reply was, treacherous computing is a major threat to our freedom. I think I would agree, and it is treacherous computing. Let's look at information and validation. As I mentioned earlier, applications will be able to query document revocation lists for the latest document revocation lists. Not all applications will implement that. So far, there are no TCP-enabled applications. However, some application vendors have already begun at looking at additional digital rights management, not just time-based, but also revocation-based. For example, you may wish to want to be able in a company to implement mandatory access control. Only employers can access the data. But even after that, you as the creator of a document may wish to have the ability to at some point enforce that the document will be superseded with a new version. For that, you need to be able to recall the document that you have written, but you don't know who has that copy of the word document. It could have spread anywhere. Consequently, what you need is our servers that allow you to invalidate and revoke documents. There are a number of reasons why a document might be placed on a DRL. Application vendors could, though I suspect they will not because I believe they do not wish to take the heat for such a step, application vendors could invalidate a document generated by a specific application. If it comes out that your application was cracked, was hacked, was stolen, and the application vendor finds out which of these federal numbers has been spread all over Dutella, the application vendor could revoke all documents ever generated by the application. So not only will the application stop working, but any document you've ever generated with it will no longer display on anybody's computer. I don't think the application vendors will do that. I think it's too ambitious. I believe the legal ramifications are too sketchy even for the application vendors. It could be mandated by a court order. For example, the document in question might contain the horsemen's of the infocalipse, instructions for narcotics trafficking, job pornography, the next version of DCSS, whatever the case may be, whatever the government doesn't want you to see, whatever the vendors don't want you to see, if they can take their case to a court and the court will issue injunction, that the following leaked document, the following information is not in the best interest of, or is against the law I should say, then your documents could be invalid globally. It could be local illegal content. Pictures of women without veils are illegal in Muslim countries. As I mentioned, copy control ciphers are illegal, or at least the content providers claim are illegal to be republished in the U.S. as the DCSS DVD CCA case showed. The list of reasons is essentially unlimited as it is for censorship. It facilitates intelligence collection, documents signed by user keys, very much simplified activity correlation. Yes, you can have multiple keys, but how many keys are you going to have? Two, three, five, ten? You won't have a hundred, and even if you had a hundred, how do you keep track of a hundred keys? Especially if it comes out that you have to pay per key because, of course, very signed ultimately will not sign your keys. For free initially, sure, you may not have to pay, but do not believe for a moment that the service will be free in perpetuity. A globally unique document at this, of course, obviously is facility traffic analysis, and this preemptive information validation greatly simplifies information flow control if information has leaked out, say, by a disgruntled government employee who decides that they wish to share with the public some of the shenanigans that the government was up to, they can just take the document and invalidate it. Law enforcement needs. The moment you have DRM, the moment you have digital signatures on documents, the moment this key is being kept in hardware and can be proven to have never left the hardware because it's a hardware security module, you have undeniable proof of authorship. Law enforcement likes undeniable proof of authorship. Courts like undeniable proof of authorship. Proposing parties like undeniable proof of authorship. You have the document I've talked about. Now what happens if a document gets invalidated? Let's say there's a document that contains what the NPA asserts is illegal decryption software. Let's say the document gets invalidated. You still need to be able to access the document in court to prove that this guy in fact was trafficking in a mathematical equation that could be used to decrypt Snow White. Well, needless to say, there will be special versions for special people that have different rules of access control that law enforcement purpose, evidentiary purposes that these special versions, however, will never leak out into the public because just as the applications I mentioned earlier, they're key to a specific motherboard. They simply won't run on any other motherboard. Will the TCP meet government requirements? Let's ask Microsoft. Mari Huarez, the Microsoft palladium, which is the TCP variant product manager, said we're talking to the government because there are governments in the world and not just U.S. governments, all of which needs to be met for a global initiative such as this to actually take off. Let's quickly look at Fritz Hollings' bill. I was mentioned briefly earlier. Fritz Hollings' bill's objective is to plug the analog hole. Fritz is a senator in the U.S. Senate with 2048-bit RSA. What does this mean? Encrypt monitor out, encrypt video out, encrypt audio out. Do not give the user an ability to get at the clear text, the raw analog data coming out of a mini-dint jack. In Microsoft's case, they also plan to additionally encrypt the keyboard. This bill would make it illegal in the United States, if passed, would make it illegal in the United States to sell in the future, sell motherboards that are not equipped with TCPA-compliant computers. Earlier you may have thought this is just insane. Nobody will buy this stuff. You won't be given a choice. You will buy it. Or what else could happen? Let's take another quiz. What is the penalty a person selling a non-TCPA-approved computer will face under the Hollings' bill? Answer it. A fixed ticket. Anybody here believe it's going to be a fixed ticket? All right. We have a few. You guys lay off these drugs. I know it's DEF CON, but still. We have six months in jail. Who thinks it's six months in jail? Nobody. And then answer C, a $500,000 fine and five years in prison for the first computer you're selling that doesn't comply to the TCPA. Double that for each subsequent offense. All right. All right. We're making progress here. That's correct. The correct answer is C, $500,000 fine and five years in prison for the first computer you're selling and potentially 10 years and a million dollars for each subsequent computer you're selling. But Palladium will be... It releases open source. We have good news. Microsoft announced that Palladium's source code will be published. The group VP for Windows says we're trying to be transparent in all of this. Some take this as proof that Microsoft has changed its business practices. Now there's continuity remain skeptical. Yet onto another quiz. Why is Microsoft releasing their source code? That just seems out of character some would think. Here are the answers. Answer A, Microsoft intends to place Microsoft Office under the GPL in 2003. Answer B, Microsoft will release the Windows source code under the BSD license in 2004. All right. All right. Yeah. BSD. Go BSD. I'm a big free BSD myself. Answer C, Microsoft has little choice but released Palladium as open source because the hauling spill requires it. Yeah. Yeah. All right. Answer C, S28 requires that, and I quote, the security system standards shall ensure that any software proportion of such standards is based on open source code. So maybe we'll have to wait for NT under the GPL a little longer. Use of KPMs is voluntary. You'll hear that all over the place. One thing that Stuart Orkin, security officer from Microsoft will guarantee is Palladium will be off by default. Absolutely true. You don't need to run it. You don't need to boot your computer. Using gasoline, using gasoline, that car is an opt-in technology. What I found is a rare piece of history. It's a wood gas carburetor. After Germany and World War II had been covered from its oil reserves, they mounted these wood, basically it's like a big oven, big stove that gets fired from below. You put wood in it. If heated dry, it generates flammable gas that you can then feed into your car. You don't get much performance out of the car, but it will move the car forward. If that's all the functionality you want out of your computer, that's absolutely correct. You will not need to use Palladiums. It's totally voluntary. Absolutely. No doubt about it.  No operating system vendor would ever dare to block undesirable applications from running on a computer. Well, let's ask Microsoft. Microsoft's Windows media players and use a licensing agreement. Microsoft may provide security-related updates to the operating system components that will be automatically downloaded onto your computer. These security-related updates may disable your ability to copy and or play secure content and use other software on your computer. It's in the end-use licensing agreement right now. So would the disabled applications running on your computer, once they can, I think some might say they will. Microsoft says they will. Let's take a quick look at the digital holes in phase one. The op-codes are on plaintext on the bus, meaning you can mark them off. The solution is bleeding obvious. In phase two, the encrypted CPU instructions will not be decrypted until they hit the CPU, in which now you get a decap, now you get a decap of P5, you get to work down your layers. It gets nasty. It gets hideously expensive. Users can select non-TCP-approved operating system for minimum functionality. Obvious solution, prevent the non-approved OS from accessing CPU supervisor mode. Jeffrey Strongly with AMD said who is very much in on this, there will be new modes and new instructions, a whole new class of microprocessors not differentiated by speed but by security. They're adding a mode to the CPU. This new hardware architecture involves some changes to CPUs which are significant from a functional perspective, said Mario Juarez with Microsoft whom we quoted earlier. Yes, it will be significant from a functional perspective. If you don't have one of the certificates, you will have no functionality. Well, you can always run a real mode. Nothing will prevent you from running the CPU in real mode. You're certainly welcome to do that. The TCP may not succeed. In fact, I believe it will not succeed because there are people like a lot of Ross Anderson's writing effects and people like me giving talks. But it might succeed. If it will succeed, process ID, let's take a look at that. Big strategic mistake. Intel went alone. AMD saw an ECPR victory. Publicer rejected it. There was another reason it wouldn't actually have done what they wanted to do. TCP might process ID just wasn't aggressive enough. And the online privacy groups were completely ignored. Intel thought they could just steam over everybody. It blew over their faces. They've learned now that they're coming around for round two. They are a bit more savvy. They've learned their lessons. They've built a broad consensus Intel, AMD, Motorola, all the BIOS vendors that have ever mattered. The system vendors and the application vendors that matter are all on board. That makes it a lot easier to pull things off. There's a two-pronged technical and legal initiatives. As I mentioned, the TCPA, Palladium, et cetera, is on one side. Senator Hollings and his bills are on the other side. There's, in fact, there's a companion bill in the house. And the online privacy groups, at least according to the TCPA, were briefed early. Which platforms will be enabled by TCP? I took this from the website, the banner that is. If you look at the image, you will see laptops, servers, PDAs and mobile phones. Mobile phones are actually the next big thing for the TCPA. Which is why Motorola is involved so actively. In future versions, games, digital content, streaming MP3, all this stuff will be streamed under the device, under 3G. They then want the user to be able to copy their music off the handheld device, to copy the games off the handheld device, hence when you TCP on the mobile. What will be the end result? According to John Manfredelli, the general manager for the Microsoft Polydian Business Unit, the end result is a system with security similar to a closed architecture system, but with the flexibility of the open windows platform. I read this and I was wondering, what is he trying to say?  But they will make you maintain the system by all the equipment. So pay for the equipment, pay for all the maintenance without them actually being required to provide all the infrastructure that a timeshare system would. In some sense, Polydian and the TCP are the offline version of .NET. All the security benefits for not allowing the user access to their own applications and their own platforms without any of the costs. At this time, I would like to run through this as quickly as possible, but we're low on time here. I'm willing to take any question you have or at least try to take any question you have. If you email me, I'm not reading email during DEF CON. I know it's a hacker con, but folks there better things to do. At DEF CON, I'll answer later or talk to me during the con. Find me somewhere. There's some questions. I see one right here. Yes, sir. Quick, come up. I can't hear you. Oh, what are they going to do against the terrorists smashing the key servers? I think the belief is that the key servers will be replicated. The system that the key servers will be replicated that the network is sufficiently rigid at this point in time to not be subjected to terrorist attack. What are they doing currently for you being not being able to install Microsoft Office unless you contact back to Microsoft? The answer is during 911, people couldn't install an office, but terrorists, whether or not you can use your software is another concern to Microsoft's business model. There was somebody on the left. Yes. Come up a little bit if you have a question. I can't hear you if you're further back. What happens if the root key becomes compromised? I don't know because I don't even know who holds the root key. Presumably the same thing that would happen if a major CA root key becomes compromised. The odds of that happening are extremely low. If you look at various science bunkers, if you look at some of the other major commercial CA's, the security measurements they put in place, the chance of compromise is low. I don't know what the strategy is. Yes, sir. Where is Apple Computer? Apple Computer is watching. Apple Computer is not, to my knowledge, on board, but Motorola is. And when Microsoft decides someday that Microsoft Office requires these features in the CPU or it will not display documents generated on the Windows platform, which they intend to. And Microsoft will simply go to Apple and says, Apple, you have two very simple choices. You can implement DRM by using Motorola's CPUs with DRM capabilities built in or we will no longer release Office on the Mac OS X platform. I don't think Apple can afford that. Come up if you have any questions. I can't hear you if you have more than a few lines. Rolls down, yes. That of course is a question only to be left for the courts during litigation after the laws have been built. My understanding is, certainly from reading the Hollings bill, and I'm not an attorney, I'll defer this to some of the attorneys in the audience, that the Hollings bill is by no means just limited general purpose computers such as motherboards, but essentially covers any of our digital devices that the content holders feel may infringe on the copyright. Yes, sir. Yes, I should mention that my apologies. The Hollings bill does not mention TCPA by name anywhere. In fact, it makes absolutely no reference to any technology, any specific technology by name. It just happens to describe a capability that would need to be implemented that as it so happens simultaneously has become available out of the marketplace. What a marvelous coincidence. I beg your pardon. How can you fight this? You can fight this by speaking up. You can fight this by educating people about some of the negative... You will hear a lot about the positive consequences of TCPA and Palladium. You will hear how it will protect your computer from viruses and worms and all these other promises. At that time, I think it's helpful to point out what some of the potential negative consequences are. Perhaps you can come up with a solution that will give us at least much of the positive without enabling all these negatives because nobody is standing up there as far as the vendors are concerned. We plan on revoking your documents. No, I do have to read through the lines as to what's going on. So, point it out. My slides... There is a version on the CD that is a couple of weeks out of date. The slides will show up on Cypherpunk's Tonga as soon as I've had a chance to upload them and unfortunately I had a hardware failure a few days ago that I'm still recovering from. But it will be on Cypherpunk's Tonga if not today, if not tomorrow and certainly by next week. Yes. Epic and EFF? Where are they in terms of lobbying the U.S. government? I don't presume to speak for the EFF or Epic, but it's my understanding that they're currently investigating Palladium and TCPA to determine what their position should be. Yes. From an antitrust, and again I'm not an attorney, antitrust typically only applies if you have some... It's typically only successful if you don't have a broad ability by the application vendors to join. Anybody can join TCPA. If you're a legitimate application vendor you can get the application signed and the DMCA specifically says that you should not be able to read somebody else's digital rights management wrapped file formats, which I believe, but again, I'm not an attorney, essentially explicitly exempted from antitrust. Let's take somebody from over there. Yes, ma'am. Yes, I probably should point this out. The new note that will be added will be it will effectively play the role of what today is done by ring zero, but it will really be a ring minus one. So your existing ring zero code will run in ring zero being number-wise or thinking it's in ring zero. However, above it is a ring minus one that determines which memory space your ring zero code can sub-allocate to your ring one, two, and three code. So from a compatibility perspective, you will still be able to run all the existing operating systems and all the existing applications. They will not be able to get any of the protected storage or any of the other information that's protected by the TPM. From your OS perspective, what's happening above it is totally transparent. Yes. Oh, Sony is a special case. Sony, of course, is both... Microsoft is somewhat of a small content provider. They have Microsoft and we've seen a few. But they're not so much in the content game. Sony is both heavily in the content and heavily in the computer game. What... If you look at the membership lists of the various groups fighting for legal protection of their copyrighted work by means of deconian technical means, you will find that there's very little overlap. It appears that the vendors made a decision to choose one of the four to fight in. Be that either the content provider four or the technologist's four. Sony is very heavily involved in the content technology for us. Not so much in the content for us. It appears they've chosen to fight the fight in the content for us rather than the technology for us. For the long-winded answer. Yes. Again, that's the question for your attorney only after the laws have been passed by Congress and signed by the president. And even then the question probably can't be answered until there's been some case law. I'm running over time here. I'll take one more question after yours. The answer is I don't know if this is the answer. I choose to believe that it's not a digital rights management that digital rights management the requirement does not come into play unless there's actually some digital rights management that can take place. So for say if you have a new file format in which none of the content providers publish their digitally right-managed content then you're probably okay. If you have no purpose computing platform things might get dicey. One more question. Let's take some in the back but you have to step up because I will not be able to hear from where you stand. That's an excellent question. Most of the average users couldn't care less as to whether they can compile their own operating systems or their own applications. In fact, most average users probably would happily entrust the security of their computer to the FBI and the Office of Homeland Security and many average users actually probably would support a mandate for the Office of Homeland Security to remotely administer computers for security. How do you address it by users like content? That's a good example. Users like content even non-hackers, non-sophisticated computer users have been bitten at one point by the Napster bug and it did a marvelous job in bringing to the user the promise of getting content for free with the user interface they could use and having this become addicted one can perhaps educate them that the supply is about to be cut off. Thanks for your time. I don't want to take too much time with the next speaker.


In times of crisis, I think that it's absolutely paramount for leaders to be able to both stimulate short-term and long-term results, and the field of publishing, the field that Quartz is in, is probably one of those industries that is among those most disrupted right now. Not focusing exclusively on cost cutting for the short-term return, however, it's important to focus on the core, but ultimately leaving room to really make sure that you're saving space for innovation, because ultimately growth is really going to be responsible for driving that long-term value in the future.


I'll give the talk on behalf of MeeChin. The nonlinear feedback shift register, NFSR for short, is a common component in modern cryptographic primitives. There are a lot of lightweight cryptographic algorithms built on NFSRs, including stream ciphers Trivian, Grain, authenticated cipher ACORM, block ciphers Catine, Catine and hash function Quack. Most cryptographic primitives, including NFSR based cryptosystems, can be described by tweakable boolean functions, which contain secret variables and public variables. The algebraic degree of these boolean functions plays an important role in the security. In fact, a cryptographic primitive with a low algebraic degree is vulnerable to many known attacks, such as higher order differential attacks, IOD break attacks, Cuber attacks and integral attacks. Cuber attacks and higher order differential attacks are most powerful against the NFSR based cryptosystems. The based non-key recovery attack on Trivian Cuber attacks and reach 799 rounds. The best known distinguisher on Trivian covers 839 rounds. The full grain 128 was broken by dynamic cube attacks. These attacks exploit low degree relations of the tweakable boolean functions. That is the low degree relations between the heavy base and the key stream base. A boolean function can be written as the sums of term, which are supersets of Ti, and the terms, which means at least one variable from Ti. The basic idea of Cuber attacks and Cuber testers is that the symbolic sum of boolean functions F by assigning all possible values to Ti is exactly FS, exactly FS. Cuber attacks work by trying to find low degree polynomial FS in secret base, while Cuber testers work by trying to distinguish FS from random functions. It is difficult to compute the exact IOD break degree for modern cryptographic primitives. After years of development of cryptanalysis, two major trills are proposed for estimating the upper bound on the IOD break degree for iterated permutations. One is based on worst spectrum. The other is based on division property. However, for NFS based crypto system, there are few trills for estimating the IOD break degree of NFSR systems, except symbolic computation and statistical analysis. These traditional techniques highly depend on computational capacities, and the results is limited by the computational resources. For example, so far, cubes with twice less than 54 have never been utilized in cryptanalysis against NFSR based crypto systems. So to gain better attacks, one has to utilize more computational resources, which could turn out to be very expensive. In this talk, we devote our attention to evaluating the IOD break degree of NFSR based crypto systems. To overcome the existing limitations, we exploit a new technique called numeric mapping to iteratively estimate the upper bound on the IOD break degree for the NFSR systems. Based on this new tool, we develop an algorithm for estimating IOD break degrees for NFSR crypto systems. As for an illustration, we refine the algorithm for trivial like ciphers, including trivial, credian, and trivial SC. First, let's see the definition of numeric mapping. Let F be a boarding function on M variables. The numeric mapping mipes the boarding function F and M integers to one integer. The numeric mapping is denoted by capital DEG, DIG. Here, AC are the coefficients of the IOD break normal form of the boarding function F. The numeric degree of composite function is defined as follow. Then we can prove the IOD break degree of composite function is less than or equal to its numeric degree. An NFSR based crypto system usually consists of an updated function, G, and an older port function F. The internal state is updated by the updated function, and the older boot bit is generated by the older port function F after an initialization of sufficient number of runs. Keep in mind the IOD break degree of a composite function does not exceed its numeric degree. We can easily show that this factor can be used to the NFSR based crypto systems. Let's see an example. Suppose we have an NFSR with size eight, and XT is the update function. Suppose we want to estimate the IOD break degree of X16, the updated bit at the clock 16. Then we can, it's racially compute X9, X9, X11, X12, X14, and then by the numeric might be, we can calculate the numeric degree of X16, and get that to be six. We can also check that the IOD break degree of X16 is six by calculating the IOD break normal form of X16. So the numeric degree of X16 is exactly the same as the IOD break degree. This fact implies that we can get an accurate estimation of IOD break degree using the numerical mapping without computations of the IOD break normal form. The IOD break degrees of output base and the internal states can be estimated iteratively. This estimation is described in algorithm one. In the algorithm, the update function G is written as a vectorial boolean function which takes consideration of the shift operations. And DIGA-ST is a procedure for estimating the IOD break degree. When setting the DIGA-ST to the numeric mapping DIG, this algorithm gives an upper bond on IOD break degree of the output of it. To reach a tighter upper bond, we use a more dedicated DIGA-ST rather than the numeric degree mapping. Later we'll show the application of this algorithm to Triven-like ciphers. We introduce Triven-like ciphers first and then based on our observations on the update functions, we formalize a linear time algorithm for estimating the IOD break degree. The internal state, which is denoted by ST at clock T consists of three registers A, B and C. The update functions update three Bs each time as shown in equation four to six, eight of which is a sum of a single quadratic term and some linear terms. The quadratic term consists of two adjacent bits. After an initialization of n-rumps, the cipher output a key stream bit using the output function f. Triven and Triven SC exactly fall into this kind of a cipher and the crivian is a variant of Triven. These three ciphers use different length of key and IV but all of them iterates 1,152 rumps in the initialization. The procedure for finding an upper bond on the IOD break degree of the output bit after n-rumps proceeds as follows. First initialize the degree of the initial state. The initialize the degree as denoted by D zero. Then iteratively compute DT for T varies from one to n. Finally, apply the numeric mapping to calculate an estimated degree for the first output bit. In the calculation of DT, two procedures are used, digomal and the numeric mapping for dealing with the quadratic and the linear parts separately. This estimation is described in algorithm two. We just skip the details. Algorithm three provides an instance of digomal. On the line in this algorithm, there are several lemurs which are proved in the paper. The details of the proof are omitted in this talk. Based on this lemur, we can prove that algorithm two output an upper bond on the IOD break degree of the first key stream bit for an n-round triven-like cipher. One thing to note is that algorithm two has linear time and memory complexity. In the following, our experiment reveals some bond on the IOD break degree of triven-like ciphers. First, we will the key and IV be sufficiently mixed. The experiment shows that the initialization should contain more than this number of runs in the third row. For example, for triven, the initialization should have more than 907 runs in order to make the key and IV sufficiently mixed. This was done by taking all the key and IV base at input variables. Second, when will the IV be sufficiently mixed? In this case, we take a subset of IV as input of variables and the key as parameter. The experiments show that the initialization should contain at least this number of runs. Otherwise, there exist chosen IV distinguisher. Next, we did a more dedicated search where input of variables contain no additized in the bits. For triven, we exhaust all the two to the 25 cubes of size 37 to 40 for triven. And we exhaust all the two to the 30 cubes of size 61 to 64 for crevine and trivia as a C. Then we obtained improved results as shown in this table. For example, with a cube of size 37 the distinguisher covers 837 runs. For the experiments show that the output of 837 round triven has a degree strictly less than 37. And the best also implies the distinguisher for 842 runs since a bias is detected for the output of 8. The accuracy of our algorithm is verified by comparing the exact algae break degree with the estimated degree using by our algorithm for triven from 66 runs to 426 runs. Our experiments show that when taking all the key and IVBs or the IVBs as input of variables our estimated bond is equal to the real bond for most cases. And when taking the best cube of size 37 as input of variables our estimated bond is always equal to the real bond. This figure shows the estimated algae break degree for triven under the three mentioned cases. In order to improve our algorithm we made two adaptions. First, we compute the exact algae break degree of the internal state for the first and zero runs. Second, we use a modified digger mall star to replace the original digger mall. And the rest remains the same as the algorithm two. Now it becomes hard to estimate the time complexity of our algorithm. The adapted algorithm is described in algorithm four. Applications of the improved algorithm brings new bonds for trivia as a C. However, it is not the case for triven and crevium. As shown in the table, better bonds are obtained using algorithm four. This table summarizes the main results of our paper. In summary, we have shown a framework of algae break evaluation for NFSR-based cryptosystem using the numeric mibing. We have also detailed the techniques for efficiently finding an upper bond on the algae break degree for trivia like ciphers. To the base of our knowledge, the tool is the first theoretic one for finding an upper bond on the algae break degree of an NFSR-based cryptosystem. In parallel with our work, Toto et al exploited the tool of division property to estimate the algae break degree of NFSR-based cryptosystem. The difference between these two methods is that the bond found by division property is possibly more accurate. However, our tool is much faster and use much less memory and has no limitation on the size of variables and internal state. This slide lists some directions for future work. One needs to apply the algorithm to more NFSR-based cell phones. Yeah, the second is to apply the algorithm for key recovery attacks. A third application may be general the algorithm to non-FSR-based cryptosystems. Thank you for your attention.


I really want you all to give a huge round of applause for all the interns of this Siddip group and as a mentorship of Rahul sir. It was a great project all together. Now next I'll invite the information and communication technology group to start with their presentation. Okay this is, we are starting with the presentation right now. Rural ICT is a platform between a consumer and a producer. So if a producer produce something, it should have a platform so that it can be exposed to the people who are living in city areas. So this is why we have developed this system. This system has been specially developed for an NGO called Abhinav Farmers Club and there are other customers as well like there is Maharashtra Organic Farmers. There are some schools from Pune as well who are using this system. So I'll start with the demo directly. So this is the admin console. This particular project has an IVRS system to it. IVRS system is interactive voice system which is something like you call on some number and it gives you interactive orders press one to do this, press two to do this. So this particular web console is only accessible to an admin of an organization. So here IIT Bombay is an organization and let's say IIT Bombay is divided into subgroups which are normally separated by geographic locations. So for example our AFC is a customer. So AFC would have a group in Hingewadi. It would have a group in Mumbai. So it is something like that. Now each group in this would have an admin which would be handling all the operations for the customer. So I'll go to parent group. Now this barcast tab would have a recorder which would record an audio and after it records you need to upload the audio and it broadcasts. So broadcast would ideally have an order, a feedback to the system, how the system is or a feedback about an organization. Response would be something like a survey. So these things can be asked to the user along with the broadcast message. Now if I select any one of these users and I place a call. The call has placed. So right now there is no cellular network here. So I can't show you the demo of this but it works. Now there is a voice message response where there is a resolution problem. Anyways there is a voice message response where all the... You are not telling the business area. Don't go into each of these things. What is the use? What your system does? Because you are called only three minutes. Otherwise he is out. Flow is something like this.  So now you are going to get him out and then he is not getting another chance. So the flow is something like this. User records something. That particular message of a user would come in the inbox. It will be processed by the admin of the organization. User records something. How will it come to the inbox? Your system is connected to the phone. Record it through IVRS. So that would appear in the inbox. In-box admin can have this order items and it can add order items, delete order items. Things like that. And he would ideally save that. So after saving this would reach to process tab which would be again processed by some other admin. And then it would reach in the process tab where you can actually view the bill. So this is a bill generation system the way it is. Here there is some resolution problem I guess. So I still not understood. A farmer using an IVRS which you are not done. Consumer using an IVRS. Consumer. Consumer. I use an IVRS. Right. And tell your system I want 10 kilo of potato. Correct. Correct. Exactly. Through voice. Through voice. Okay. I am not connected to your web. No. Somehow the 10 kilo of potato lands on my system pay first. No. It will land on your system first. Land in my house. No, no, no. Potato. That is an organization business strategy that we are living to organization. So I use your system I said I want 10 kilo of potato. Right. Why do you care I want my 10 kilo of potato. Right. Right. So that is an organization policy completely. Yes. We are not, we are just providing an interface between these two. So what used to happen previously was produce consumers used to directly call in rural areas for the potatoes. Correct. Right. Why do I need you? If I can know a farmer he will give me potato. Exactly. This system stores the order. Okay. So. Even if. Even if. Even if. No, no, no. You are not doing voice recognition. Sorry. You are not doing voice recognition. No. I am being, looks at it and says it is 10 kilo of potato. Right. If he, if he, if my voice is not good, he will give me 10 kilo onion. Yes. No, you are. He is not online buying. I am not even buying. Buying. His voice will be processed. Yes. You are sure. So. So. So actually the concept. So actually the, actually the concept is that initially there was a manual interaction between the farmers and the customers. There is a, not a single farmer. There is a farmer club which needs the system. So they used to manually call and it was difficult. So to make this process effective. We started the system where you can broadcast a message. You can broadcast text message and broadcast voice message. You make groups. Initially sort groups. You make groups of consumers. You can make groups like area wise. You make groups of consumers. Yes. They have built the system. They have other people also from our team who helped them, but they also contributed on. So they have helped in developing this. The back end as well as the front end. Yes. Yeah. So in the, in this group there can be consumers, the customers which are there. This consumers can be a part of the group and the admin can broadcast messages, either text messages or voice messages informing them that you can place your order. These are the items which are available and can record their order. They can call to a particular number at their convenience within a time limit of one or two or three days and record their order. The order comes to this inbox after the order comes here. They can listen to the order. Suppose it says two kilo potatoes, three kilo onion, and then as you say, as you showed they could. Yeah. They could build a bill and generate the bill. So two things are taken care of here. One is recording the order and second is processing the bill because earlier they used to use pen and paper to process the bill and it was a whole manual process. So two things are being addressed by the system. And apart from that, the IVR menu also asks them to record feedback and response. There are two, three options, like press one for feedback. I can't show you now because of the network problem here. Yes. So the farmer group, there is a farmer group. Yeah. So there is one person who knows computer. We will train him to use the system. Yeah. So now we have, you know, order feedback and response. Order is like when he orders, he gets a message that your order ID is this. He can even cancel the order. He can go back to the menu and there's an option to cancel the order. He can enter the item and order is canceled. And then, yeah, the both of them had worked together. Yeah. So order feedback and response is, you know, like what we are building and it can be generalized. It can also be used for registering for an event, product or service and feedback can be used for information dissemination. If you want to just broadcast information and take some feedback, that can also be done. And response is like yes and no. You can do a survey. Did you like this product? Press one for yes, press two for no and you can get a survey. These are the different users which are there, like shown here. This feedback, you can get feedbacks here from users and response can be recorded here. Yes. Whoever says yes, this response is recorded as yes and no. So these are the different, this is a particular, you know, prototype which is built, but it is, it can be used and for many other purposes like registering as a set for event, for feedbacks, responses. And even text SMS both ways can also be used. Okay. Thank you.


A Scott's mom and daughter were shocked when their stroll was interrupted by a sighting of the Loch Ness monster. Louise Power and mom Jennifer McCrae believed they spotted Nessie while they were out walking along the Great Glen Way above Temple Pier at Drum Nadroit on November 15. The pair's claim they saw the iconic river creature was registered as the 13th official sighting of Nessie in 2020. The Loch Ness spot came just next to where Louise, 38, has stayed all her life. The high school clerical assistant told how eagle-eyed mom Jennifer, age 60, saw something strange in the water while out walking. She said, mom saw it first and said, look, and I just said be quiet. I expected to see a seal or something, but we spent 20 minutes watching this thing moving slowly along the middle of the Loch. There was a wake after it, and during that time it did not disappear, it just kept moving slowly. Then it turned towards Doris with a big wave and just went under the water and disappeared. She added, I just couldn't believe it. It was quite big and whitish gray. I couldn't put an exact size on it other than it was big. We've both lived here all our lives and we've never seen anything like that before. I did believe there was something unexplained in the Loch. Now I know there is. When it turned away from us, the waters were really disturbed and we watched it for another five minutes before it went under. At the end of our sighting, it did not look as long as it did at the beginning. You could not make out its exact shape. I run and walk along that road regularly and I've never seen anything unusual before in all those years. I've been trying to rationalize it in my head since, but I'm baffled. Louise's nearby neighbor, Ross McCullough, a former Nessie skeptic, saw a similar creature in July last year. He said, I started watching it for five minutes. There was no long neck, no head, just the hump bit. I'd say it was 12 feet long and 4 feet wide at its widest. It was light gray and it went under the water, then up and then disappeared. Gary Campbell, keeper of the official Loch Ness sightings register, has accepted the encounter on November 15th as a record. He said, this is the 13th accepted sighting this year, which in a year of lockdown is incredible. Normally, there would have been half a million visitors to the Loch, but the sightings have held up with so many less people about. The mystery is as strong as ever. It just shows that whatever the situation, Nessie's not gone away and is finishing the end of the year with another unexplained appearance. It all adds to the mystery and in many ways is a vintage year for sightings. This latest one is another unexplained phenomenon at Loch Ness. We'll never have firm evidence without a carcass, which none of us want. This is a Weird Darkness bonus bite.


Hello everyone, I am Subradit Chakraborty and today I will be talking about reverse firewalls for actively secure NPCs. This is a joint work with Stefan Zimboski and Jesper Buznielsen. In the classical setting, we would like to think of two parties Alice and Bob with their private inputs XA and XB and they want to engage in a protocol to produce some outputs YA and YB respectively. And we think of an adversary sitting in the middle and observing the transcript of communication between Alice and Bob and potentially corrupting one of the protocol participants, in this case Bob, to learn some useful information. And we say that this protocol is secure if the adversary cannot cause any harm to Alice even after corrupting Bob and seeing the messages that are exchanging between the two parties. However, in the real world, it's not just Alice who talks to Bob, but it's Alice's trusted computer who implements all the operations in the name of Alice because Alice cannot compute bilinear maps in her head. So this brings us to the question, should Alice trust her computer? The computer looks nice and innocent so far, but one can never be too careful. So in particular, if Alice's trusted computer is replaced with this tampered implementation with red eyes, instead of sending the first legitimate message to Bob, it can just send Alice's password over to Bob and in the second message, send over Alice's credit card number to Bob. Bob might be a bit confused, but our adversary will certainly be happy. While one can argue that this is obviously detectable, but the adversary can be smart and it can use its own encryption key to encrypt this information or leak information steganographically. And this is not only a theoretical prospect or a concern. There has been widespread, apparently accidental bugs in cryptographic software like the poodle, the hurt bleed, Apple's go to failure, the DBN failure, lock jam attacks and so on and so forth. And while these attacks seem to be apparently accidental, unfortunately there has been deliberate corruption of hardware and software that has been done by government agencies. For example, the NSA and we've got to know that cryptographic tools and standards can be subverted. One more recent example is the Chinese chip hack that also infiltrated the hardware and affected the technology supply chain of the US on a massive scale. So this brings us to this line of cryptography, which is called post Snowden cryptography, which asks the following seemingly absurd question. Can we do crypto on tampered machines? In particular, can we get meaningful security for cryptographic protocols in the presence of an adversary who can arbitrarily tamper with the victim's computer? And in fact, there has been a statement by the ICR in Eurocrypt 2014 that much research should be done along these lines and one should develop effective techniques to protect personal privacy against government and corporate overreach. So there has been some prior works addressing these issues, starting with the work of Simons in 1984 on subliminal channels, divertable protocols, cryptography and crypto virology. Unfortunately this line of works kind of died off after the 90s and it was resurrected only after the Snowden revelations and one of the earlier works to address this was the work of Belare Patterson and Rogovay who coined the name Algorithm Substitution Attacks. This mostly studied symmetric encryption in this model and there has been works such as back.prgs by Doddys et al. So this brings us to the second part of the talk about cryptographic reverse firewall. So this model of cryptographic reverse firewall was introduced in Eurocrypt 2015 by Ilya Miranov and Stefan Davidovic. So what is a cryptographic reverse firewall? So we can think of a reverse firewall as an active intermediary or a router that sits between Alice's network and the outside internet represented by Bob here. It is a stateful algorithm that takes as input its current state and some message m and it outputs an updated state and some message m tilde. So in particular we think of the firewall as sitting on the edge of Alice's network and it sees the incoming and outgoing messages that are sent and received by Alice and it modifies these messages. So in particular Alice sends m1 the firewall malls it to m1 tilde, Bob sends m2, firewall malls it to m2 tilde and so on. One important requirement is that it should be transparent to legitimate traffic. So this means that while Alice sends a single message to the firewall, the firewall should send the same message to Bob. So it's not like Alice and the firewall are exchanging 20 messages back and forth. So in that sense Alice should be completely oblivious that there is a firewall sitting on its network. And the most important point is that the firewall shares no secret with Alice. So for example we are not delegating the trust to the firewall. So the firewall is not a trusted third party, it's just a helpful third party as I'll shortly demonstrate. So the properties from such a CRF are as follows functionality preserving. So suppose there is an underlying classical protocol in which Alice and Bob talks and Alice outputs YA and Bob outputs YB. So we want that the protocol with the firewall should not screw up the functionality. So if Alice's implementation is honest, the protocol with the firewall should also allow Alice to output YA and Bob to output YB. So this is extremely straightforward. The second more important property is that of security preservation. So suppose there is an underlying classical protocol that satisfies some security requirement. Say this is modeled by some crazy game in which the adversary corrupts Bob and might have oracle access to multiple copies of Alice and so on. And still the adversary cannot break the security of the protocol. So now we want to say that if there is a firewall and if Alice's implementation is corrupt the security of the protocol will be preserved. So in particular the protocol with the firewall should satisfy the same security requirements X but now Alice's implementation is replaced with any efficient corruption. And we want to say that the adversary also loses in this firewall protocol when it gets access to this firewall diversion of Alice. And here we make a distinction between strong versus weak security preservation which I'll shortly explain. And I want to stress this point that we always assume that there should be a protocol that is functional and secure without the firewall. And the protocols that are not functional in the first place are not interesting. So the types of corruption that we will be considering are suppose there is a classical protocol that satisfies some functionality F and security requirement S. So the first model of corruption is strong corruption where we assume that there is any efficient arbitrary tampering strategy and secondly weak corruption that says that the tampering strategy can be arbitrary as long as it does not break the correctness of the protocol. However, it might still behave arbitrarily a negligible fraction of time. For instance, suppose there is an oblivious transfer protocol in which Bob's first message is uniformly random over some set and Bob learns MB and it should not learn the other message whereas Alice should not learn the bit B. Now it might happen that for a particular choice of the first message of Bob say all zero strings Alice just encodes the XOR of both M0 and M1 into the output represented by Z1 tilde here to Bob. And Bob when it is corrupt can just send this all zero string to learn the XOR of the two messages which otherwise would not have been possible for a secure OT protocol. And the third property that we need is that of exfiltration resistance which says that a corrupt implementation of Alice cannot leak any information to an attacker via the reverse firewall. So in particular in the world above Alice's tampered implementation is clubbed with the firewall and we see this as a joint party and in the second world Alice is honest and is clubbed with the firewall and we want to say that in both these worlds are indistinguishable and again we make a distinction between strong versus weak exfiltration resistance. So when I say strong I'm referring to the strong model of corruption and weak I'm referring to the weak model of corruption and in this case if Bob is corrupt we call security against peer party else we call security against an eavesdropper. So the first work of Miranov and Stephen W. David's constructed reverse firewall for arbitrary two-party protocols via constructing an RF compatible private function evaluation protocol and their techniques used re-randomizable garble circuit and re-randomizable OT. And they also show a general method to compile any protocol to an exfiltration resistant protocol. However the disadvantage is that it recompiles the protocol into the encrypted domain which makes the protocol not transparent. So in the follow up work by Doris Miranov and Stephen W. David's they construct secure message transmission protocol in the RF setting and there is another follow up work which shows how to construct reverse firewalls for functionalities that are realizable by smooth projective hash proof systems. And finally in a recent work Ganesh Magri and Vanchuri shows how to construct CRS for interactive proof system via malleable sigma protocols. So quoting Miranov and Stephen David's from their original paper the holy grail would be a full characterization of functionalities and security properties for which reverse firewall exist. So in this paper we solve this open problem and give a full characterization of such functionalities. In particular we construct multi-party computation with reverse firewall. So in this setting there is a bunch of parties each with their private inputs XI and they want to compute a function F over their inputs. And a subset of these parties can be corrupted by the adversary and we want to say that nothing other than the output should be leaked that is F of XI to XN. And this can be formalized using the real world ideal world paradigm which I will not go into. So in the reverse firewall setting again each of the parties have their own private inputs and a subset of them can be corrupt as before but now the remaining honest parties can also be corrupt albeit in a functionality maintaining way. So we consider all the parties in the MPC protocol can now be corrupted, some subset of them can be corrupted in an arbitrary way as in the original MPC protocol and the remaining honest parties can also be corrupt but in a functionality maintaining way. And for those parties which are corrupted in a functionality maintaining way we replace those parties with the party with the tampered implementation of the parties clubbed with the firewall and we call this parties as this joint parties with a hat. So in particular PI hat is the firewall composed with PI and we want to say that when the parties the honest parties are honest the firewall protocol should not break the functionality. Security preservation says that now when we replace this PI's with PI hats the security property of the MPC protocol should be retained and exfiltration resistance says that for example P3 hat cannot leak any information via the firewall to any other parties and similarly we can define it for P1 hat and P5 hat and so on. So in this paper we construct the first actively secure MPC protocol in this setting and we show a generic compiler that takes any passively secure MPC protocol and compiles it to an actively secure MPC protocol in the RF setting. So the way we do that is we take the GMW compiler and show how to make it reverse firewall compatible. So the main contribution of our work is how to construct a multi-party coin tossing protocol in this setting and finally we show that all these individual building blocks when they are made RF compatible they compose together to give the final actively secure protocol. And as a result of independent interest we also show a compiler for reverse firewall in the broadcast module. So let us just quickly recall ourselves about the blueprint of the GMW compiler. So it takes any semi honest MPC protocol PI and compiles it to PI prime as follows. All the parties first commit to their input by running an input commitment protocol and then the parties fix their random tapes by running a coin tossing protocol and finally they run the parties then run each step of the semi honest MPC protocol and prove in zero knowledge that the computation was correct and is consistent with their committed inputs and their random tapes. And the claim is this this protocol is actively secure by now it is well known. And now to lift this compiler to the reverse firewall setting we need to replace each of this highlighted component into the reverse firewall counterpart. So I will mostly focus on the coin tossing protocol which will give you an idea about the techniques that we use for the rest of the protocols as well. So for that we let us briefly recall ourselves about non-interactive zero knowledge proofs which allows a prover to convince a verifier that he knows a witness without revealing the witness and the completeness is that the honest prover should always convince the verifier if it knows the witness soundness is that the cheating prover cannot convince a verifier if the statement is not in the language. And we want the property of simulation sound extractability which says that even if after seeing many simulated proofs if the adversary comes up with a new proof there is an extractor who can extract a witness and it is easy to see that SSE implies non-malleability. So although we are talking about multi-party coin tossing but let us just consider the case of two parties which will give the ideas behind the coin tossing protocol. So the functionality that we want to achieve is that two parties initially have no inputs and then one party would end up with a uniformly random M bit stream and the other party would get commitment to the string. So this follows by the classical commit and proof paradigm where P1 first samples a string S commits to it and then proves in zero knowledge the commitment is consistent and sends the commitment and the proof to P2. P2 also samples some string S2 and sends this S2 to P1 and then the P1 computes the final string as the XOR of S1 and S2 and commits to this string S and proves in zero knowledge that the initial commitment C1 was also consistent and C is also consistent with the choice of the randomness and the strings S1, S2 and sends this final commitment and proves to P2 and the output of P1 is the XOR of these two strings and the output of P2 is the commitment to the string S. Now let us consider this protocol in the reverse firewall setting, let us consider the case where P2 is corrupt and now P1 is corrupt in a functionality maintaining way. So what can go wrong? First P1 might commit to a bad string S1. Also the randomness R1 that is used to commit to S1 might leak information about the committed element and finally the final commitment proof might also be leaky. Now let us consider the case where P2 is corrupt in a functionality maintaining way, surely it can choose a string S2 that acts as a subliminal channel to trigger some bad behavior of P1. So if we want to construct a coin tossing protocol in the reverse firewall setting we should be able to account for all these facts. So let us see how to do it. So the first idea is that when P1 is corrupt and there is a firewall sitting on top of P1 it should be able to mall the commitment string C1 so as to transform itself into a commitment to a uniformly random string with fresh randomness and it turns out that if we can replace the commitment with any homomorphic commitment scheme which allows for mulling and re-randomization this is sufficient. However, at this point the proof pi1 is no longer a valid proof and for the firewall to maintain the functionality it should be able to mall the proof as well. However, there is one inherent difficulty here since the proof is simulation sound extractable and this implies non-malleability by definition it cannot be mauled by the firewall. And also a bigger problem is that even if the proof is malleable somehow the firewall does not know how to mall it since it does not know the committed string or the witness in the first place. So to resolve this we use the idea we replace the NISIC proof of knowledge or the simulation sound extractable NISIC with a controlled malleable NISIC proof system that I define next. So this was introduced in the paper of chess et al from Europe Group 2012. So this is a NISIC proof system that satisfies completeness and soundness as before and in addition it satisfies malleability which says that given a bunch of proofs valid proofs for some statements there is a public evaluation procedure that takes these statements and proofs and malls it into a valid proof for a transform statement T where T belongs to some class of transformation. Note that ZK eval does not need the witness to compute this valid proof and we want re-randomizability which says that any proof can also be re-randomized in a way that it is indistinguishable from a fresh proof. And we want derivation privacy which says that the output of ZK eval is indistinguishable from the case if the prover was giving a fresh proof on the transform statement and the transform witness. And finally we want the property of control malleable simulation sound extractability which says that even after seeing many simulated proofs if the adversary comes up with a proof pi star for some statement X star there is an extractor who can extract either the witness such attesting to the fact that X star is in the NP language so far this is same as SSNZ but also a tuple such that X star can be explained via this statement X prime and the transformation T such that X prime was previously queried by the adversary and basically it was shown in the paper that assuming decision linear assumption one can instantiate this control malleable physics in particular the grad Sahai proofs are control malleable. So now equipped with this homomorphic commitments and control malleable proof let us see how to do reverse firewall for the coin tossing protocol. So the idea would be the firewall should mall each and every step of the protocol and this is how it does. So after receiving the first C1, pi1 it the firewall computes a fresh commitments on its on its own and homomorphically adds the commitment and defines the transformation to be this homomorphic operation and derives a proof by using this ZK eval algorithm. So in fact you need to re-randomize this proof as well. So first it re-outputs this proof using ZK eval and re-randomizes the proof and sends this to P2. P2 then sends S2 and now the firewall malls S2 by the offset it chose in step one and sends this mall S2 hat to P1 and when P1 sends the final C, pi it also appropriately malls the statement and malls the proof and hands over this proof to P2. So one can show that the output of the coin tossing protocol is consistent. So the firewall did not screw up the functionality and this is quite easy to see. And in our paper we show that if the underlying building blocks satisfy the properties required the firewall satisfies security and exfiltration resistance against P2 in this weak model of corruption. Now the coming to the input commitment protocol. So here the party PI has its input xi and ri and it commits to its input and then proves in zero knowledge the commitment was consistent and the firewall protocol is the idea is very similar. So first the firewall computes a commitment to zero and hands over this and homomorphically computes the commitment and malls the proof and hands over this proof to the other parties. And we also show that the firewall weakly preserves security for P1 and its exfiltration resistance for P1 against P2. So in particular we prove the multi-party version of this theorem. And as the last missing piece we show a reverse firewall for the authenticated computation protocol. Note that after the coin tossing and the input commitment protocol the inputs and the random tapes of each party is fixed and all other parties holds commitment to all other parties inputs and randoms tape and at this point we can just run the passively secured MPC and prove in zero knowledge that each computational step is valid. So for the reverse firewall version of this we just need to re-randomize the proof which we can do using the re-randomizable musics. And we also show that this firewall weakly preserves security for P1 and its exfiltration resistance against any PJ. So finally as a result of independent interest we show how to construct a compiler for reverse firewall for the broadcast model. Note that the assumption of broadcast channels in the RF setting is a stronger assumption than in the classical setting. So we instantiate this using the dollop strong protocol and the main idea would be to transform the dollop strong protocol to a unique message protocol and this we do it by replacing the signatures with unique signatures. So at any point there is a unique choice of the next message that a party can send which is a signature and since it is corrupted in a functionality maintaining way it is forced to send this correct message. And this can be generalized for the class of re-randomizable signatures as well. So to summarize we show the first feasibility result for actively secure MPC in the setting of reverse firewalls. We show how to upgrade the GMW compiler to be made RF compatible and this we do by exploiting the homomorphic properties of the underlying commitment scheme and the control malleability feature of the underlying NISIC argument system. And we prove a generic composability theorem and show a reverse firewall for the broadcast model. So some of the interesting open problems are can we construct more efficient and round optimal MPC in the RF setting say two round MPC in the setting. Can we construct adaptively secure MPC in the RF setting? Also note that since we use non-interactive zero-knowledge proofs we rely on the trusted setup phase. So can we remove the trusted setup assumption? So with this I would like to conclude my talk and one can find the e-print version of our paper with report number 1317. Thank you.