Latest / Strachey Lectures / Strachey Lecture: Privacy-preserving analytics in, or out of, the cloud

Transcript

Strachey Lecture: Privacy-preserving analytics in, or out of, the cloud · Strachey Lectures

• 0:03
  Okay. Good afternoon, ladies and gentlemen. Let's begin.
• 0:07
  My name's Mike Wooldridge.
• 0:08
  I am head of Department of Computer Science and it's my very great pleasure to welcome you to the Hillary term straight lecture.
• 0:15
  As always, when we begin the Straight G lectures,
• 0:18
  I'd like to acknowledge I'd like to acknowledge the financial support of Oxford Asset Management who sponsor these lectures.
• 0:26
  And since their sponsorship we have been able to step up a gear in terms of the kind of lectures that we're able to offer.
• 0:35
  Getting into this lecture theatre is not in fact free. We have to pay for it.
• 0:39
  So when to use facilities like this to use fantastic facilities like this is only possible because of Oxford Asset Management support.
• 0:46
  Nevertheless, we did get them in a feature film. I hope you've all watched AlphaGo the movie.
• 0:53
  If you haven't watched AlphaGo the movie, you should go away and watch.
• 0:55
  It's on Netflix and Straight G lecture from exactly two years ago actually appears at the beginning of the movie.
• 1:03
  John, I'm sorry, I can't promise you're going to be in a feature film today.
• 1:07
  But nevertheless, it's my enormous pleasure to welcome John Crowe Croft To give this lecture.
• 1:12
  John is the Marconi Professor of Communication Systems at the University of Cambridge, where he's a fellow of Wolfson College.
• 1:20
  And it's difficult to summarise John's work briefly because he is just simply so tremendously active.
• 1:27
  But in terms of the UK, he is, I think it's safe to say,
• 1:31
  the UK's leading academic in the area of networks and has been he's been setting that agenda now for at least three decades,
• 1:39
  has a tremendous track record of some of the early work in in networks.
• 1:44
  So when we think about digital immigrants and digital natives, I'm a digital immigrant because I grew up in a world without the Internet.
• 1:52
  My kids are digital natives because they grew up and it was just all around them.
• 1:56
  But John was a true digital pioneer. I mean, he was one of the people that was creating the protocols that just makes the whole thing work.
• 2:05
  So he's a fellow of the Royal Society. I'm a Facebook friend of his, and one of my daily pleasures is seeing updates from John.
• 2:12
  They are the most entertaining updates that you can imagine on Facebook.
• 2:17
  And what can I tell you from following them?
• 2:19
  Facebook, I can tell you that he likes music and pubs, so you should really move to Oxford because you'd fit in really, really well.
• 2:26
  John, it's, it's my great pleasure to welcome John Croker off to give the lecture.
• 2:30
  Thank you, John. Okay.
• 2:37
  So settle down. I have 92 slides and we have about 50 minutes.
• 2:41
  And my mistake, I thought I had 2 hours and I thought I had an hour and a half.
• 2:45
  And on the train I realised I had an hour and 50 minutes and so, so keep up.
• 2:49
  There will be test at the end. So this is a work in two projects, both between Cambridge and Imperial.
• 2:57
  One also has partners in Nottingham University and the other one has partners at the Turing is two,
• 3:01
  where I spent half my time in London where they have two pubs of music.
• 3:06
  Although I'd say, yeah, Oxford's definitely had a Cambridge in both those steps.
• 3:11
  So and this is this is an area we've been mucking around with for a while, which is something that I think impinges on all of us.
• 3:20
  So in and out there in the cloud, there are two kinds of class, a broad classes of data.
• 3:26
  There's all the stuff that we voluntarily stick on Facebook or Twitter or Instagram, whatever, all of that.
• 3:33
  You know, it magically emerges from our mobile devices in our pocket and so on.
• 3:38
  And then there's stuff that people that have large bodies of curated data like Bill Health Service,
• 3:44
  who may be working with DeepMind or or a financial institution and trying to do fraud detection or, you know, figure out the next Facebook and so on.
• 3:55
  So so there's this this is large dataset over here,
• 3:58
  which is kind of curated and comes from some large organisation and then is that is highly decentralised
• 4:03
  sort of crowdsourced bunch of data over here that's then centralised by some of these agencies.
• 4:07
  So what we've been staring at is thinking about the,
• 4:10
  the issue of privacy and the fact that all this data is being put somewhere for doing analytics on it to, you know,
• 4:16
  maybe monetise it, maybe it's you are the product for Zuckerberg,
• 4:19
  but maybe also to work out something that's a better diagnostic tool, predictive tool and so on on health care data.
• 4:26
  So which could be, could be making money as well or something for social good.
• 4:31
  They'll be figuring out, you know, what's the best investment in the future of universities in terms of training and education.
• 4:37
  Maybe it would be to keep our pension the way it is. Oops, political.
• 4:41
  Okay, so that's the last thing I'll say for now on that topic.
• 4:46
  So so there are there are two pieces to this talk and I'll probably run out of time just at the end of the first piece.
• 4:51
  Apologies for that. The slides will be available, I think so if you're interested.
• 4:56
  In fact, they're linked off my home page as well. So the second bit will be in there too.
• 5:00
  So the first bit is about privacy, preserving analytics and a centralised cloud.
• 5:06
  And this comes out of the work with Turing and principle,
• 5:08
  with peer to peer support group in large scale distributed systems, Imperial College, London and folks in Cambridge.
• 5:14
  And what we're interested in is we have this large amount of curated data, so it could be partners that we have worked with,
• 5:20
  with the NHS, Scotland, 1.6 million patient records with upwards of 10,000 variables kept about every patient.
• 5:27
  And this stuff is naturally in some senses centralised across data centres in hospitals.
• 5:33
  There are people in Oxford working on this stuff, doing some computer science here and other folks doing cool things with this.
• 5:39
  And then the other, the other sort of large amount of centralised data is financial.
• 5:42
  HSBC is a partner in the Turing House.
• 5:44
  I think about 20% of the world's transactions go through their systems, a large fraction of UK transactions, and they're interested in, you know,
• 5:50
  predicting what's going to happen in tomorrow's book for trading, but also detecting fraud because they're required to look at it and so on.
• 5:57
  So there are motives for putting their private data centres data into the cloud which are effectively cost saving exercise.
• 6:04
  And in fact there are things they may need to do they can't afford.
• 6:07
  I was surprised that HSBC said that actually some of the things they're going to be required to do for detection are actually beyond their capability,
• 6:13
  not just in terms of number of people, but, you know, in computation. But if you do the cost of renting those resources on servers, yeah,
• 6:21
  then it comes out somewhat better because of a number of huge scale scale up properties like Amortising power supplies and cooling and efficiency,
• 6:30
  operational reduction cost by having multiple customers and so on, and also statistical multiplexing of the resource.
• 6:36
  And there's a lot of reasons so and there are other motives for putting things into the public cloud.
• 6:41
  Okay. So there's issues here about legality,
• 6:45
  which one go into there's not really time that you want the experts in some of this they're actually pretty near here in.
• 6:50
  Oh, I have a bunch of really really people have written about this stuff.
• 6:55
  But there are rules about where you do cloud processing on PII, personal identifying information, in particular in health care.
• 7:01
  Financial is very strictly controlled in the US as well as in EU and UK is in line with that and so on.
• 7:08
  But there's some practical things. Even if you stay within a national jurisdictional boundary,
• 7:12
  you want to keep your data encrypted and installed, you want it to encrypt it when you transfer it.
• 7:17
  And post-Snowden, that's been fairly standard.
• 7:19
  If you buy storage on Amazon or Google Cloud or whatever, and then in rest encrypted and people default to agents and transfer.
• 7:28
  But you'd also I'd like to go a bit further. You'd like it to be encrypted during processing.
• 7:33
  Because there are threats. I'm going to talk about those threats because that's what we're trying to mitigate.
• 7:39
  Okay. So what on earth with the threat to be to when your processing data is coming off the disk, going to the CPU?
• 7:46
  What could possibly go wrong?
• 7:49
  There are also a whole bunch of other things I really don't have time to go into about, you know, key management across multiple organisations.
• 7:56
  A horrible, huge, massive problem always has been. I don't see any stop to that.
• 8:01
  But the bottom of the bottom line on this slide is sort of the word enclave and secure enclaves is something you may have come across.
• 8:08
  It showed up, I think, in the FBI versus Apple fight over a terrorist's iPhone.
• 8:15
  And Apple was like, oh, we can't actually decrypt this phone for you. Sorry, actually isn't doable by us and not at least in the affordable way.
• 8:23
  In fact, it turns out there were some workarounds for that obscurely.
• 8:26
  It doesn't matter about the details, but the reason is just to do with the kind of technology they use for where keys the cap.
• 8:32
  But actually even if you had been processing things on the processor that that iPhones use,
• 8:37
  which is kind of arm variant, there's technology for running a trust zone, as they call it.
• 8:43
  And that's a cool thing. And Intel have a similar thing, which is what I'm going to talk about called SGX,
• 8:49
  which is software got extensions of the intel processor, which you could use to gods.
• 8:53
  What's going on in some senses during processing okay up to some limit AMD have another technology which is halfway between what Intel and arm do.
• 9:03
  Cherry is a Cambridge local specific thing, which we do, which we built some hardware which does a simpler and better thing.
• 9:09
  But I don't have time GDPR as legal background. I don't have time to go into the legal background, but this is why you care.
• 9:15
  You need to make your best effort at keeping people's data secure.
• 9:18
  If it's health care or it's financial and it has PII and it, then you are into very serious fines if you get things wrong.
• 9:25
  I mean, not just talking about, you know, a slap on the wrist and $50,000,
• 9:30
  we're looking at 95% of GDP a year while you're still doing the wrong thing.
• 9:33
  Not funny. 5% of your gross profit for your company.
• 9:36
  Sorry. Okay. So the project we have at Imperial and Turing is called Meru for obscure reasons.
• 9:44
  And what we're interested in is trying to see if we can do analytics in SGX in this extension to the Intel processor.
• 9:52
  And so we going to dive into a bit of detail here about how we're doing that.
• 9:56
  So I'm going to talk a bit about trustworthy data processing in an untrusted cloud.
• 9:59
  That's kind of the starting point here. So we're looking at people have a lot of curated data is high value,
• 10:04
  the bad guys out there will want to try and attack it and it's in central locations for good reasons.
• 10:10
  You might want to do machine learning over this data because you might want to run, you know, create a a Bayesian model of the data.
• 10:18
  You might want to do some interesting image processing over all the retinal scans, all the images, a whole bunch of things you might want to do.
• 10:24
  And then having trained up those systems, you might give them to chips. So when you walk in with some extra symptom, the GPU runs the thing on you.
• 10:30
  No privacy problem at that point. You've got a direct relationship and they all you need to go to the hospital right
• 10:35
  away for an eye operation because BLAH might even have a model which we have done,
• 10:40
  which will predict that if you don't get in by Tuesday, Wednesday will be a day too late,
• 10:45
  which is, you know, the sort of thing that was high value to people. Okay.
• 10:49
  So we're going to have a look at what's the what's the underlying and problem space,
• 10:53
  the a bit of an overview of SGX and and so on and how then we map a machine learning or a data analytics platform onto SGX.
• 11:01
  And at the end of this, I'll try and remember to say what the what the shortcoming of all this work is so trustworthy data processing.
• 11:10
  So the cloud has taken off because a lot of people kind of trusted the cloud provider and the cloud provider didn't trust the people, the users.
• 11:18
  So the model traditional model is you've got sort of trusted operating system and harbour and the cloud providers go out of their way.
• 11:25
  They have very, very good processes.
• 11:26
  If you go visit Google or Microsoft and go to an as your site, their processes for managing, you don't get to get,
• 11:33
  you know, administrator log in or, you know, to to sue do anything that just doesn't happen.
• 11:37
  They're really, really good physical access control. They really pretty good about that stuff.
• 11:41
  And what they're trying to do is, you know, to isolate users from each other. So and they use virtual machines.
• 11:47
  And this is where I came in way back when in Cambridge, we were building a hypervisor called Zen, which is widely used in Amazon and other places.
• 11:54
  So for running multiple guest operating systems, virtual machines, and you get protection between those kind of.
• 12:00
  Or do you. Users trust their application.
• 12:04
  But why should they trust the cloud provider? Why should they trust the cloud provider?
• 12:08
  So historically, back in the day, when when there's no hypervisor for ships in use, that would be a cert, you know, literally an alert.
• 12:17
  There's a vulnerability about once a week. On the hypervisor.
• 12:20
  That means that a vulnerability exists such that some guests could run an app which could go and
• 12:25
  look at all the memory and all the other operating systems via a vulnerability in hypervisor.
• 12:30
  So at this point, you fix the bug and you reboot 1 billion virtual machines.
• 12:34
  At which point a lot of customers get a bit annoyed. Right? But if their data was sensitive, that vulnerability exploit could have been the bad guy.
• 12:44
  Reading all of the MPs health records when they presented with weird symptom X and then publishing it to some scurrilous newspaper or worse,
• 12:54
  you know, attacking the entire financial system tomorrow by fiddling with some of the numbers.
• 12:58
  So so this is an issue. So a solution for this might be to run a trusted execution environment.
• 13:05
  So to have some kind of way of supporting isolation in a way that the hypervisor and
• 13:11
  operating systems do not have the privileges to read across these application domains.
• 13:17
  So, you know, long story short, Intel built something to do this way back when arm built this.
• 13:24
  It's a little easier on an arm. People familiar with, you know,
• 13:27
  risk processors and ARM will know it's a highly regular architecture and adding some new thing to it in a coherent way.
• 13:33
  It's doable. And ARM also have a pretty nice full model of their systems.
• 13:37
  When they had a feature, they can figure out the consequences. For Intel, it's incredibly complex.
• 13:42
  How do you get a thing to have this thing called a micro architecture, which leads to all kinds of problems?
• 13:46
  But the idea here is that essentially you reverse this whole structure where users run their application process and it tells the operating system,
• 13:54
  which has more privilege, which talks to device drivers and storage and so on.
• 13:59
  And if you run a hypervisor that has even more privilege because it can see all these OSes and you flip that around and say,
• 14:04
  no, the application can enter an execution domain, if you like, within which is sandboxed by the hardware.
• 14:13
  Okay. So that's what SGX or an enclave is sort of supposed to do, a trusted execution environment, lots of different ways of coming at this.
• 14:19
  And there are there are several other pieces you need.
• 14:22
  But the idea is this this potentially saves you from the vulnerabilities in another device or the OS or even in library code,
• 14:30
  perhaps in runtime breaking things for you potentially.
• 14:34
  So that's shipped on various recent Intel processors.
• 14:38
  And as I say, there's an equivalence in our processes, an equivalent lambda and so on.
• 14:41
  In fact, the risk free project also has a design for an equivalent.
• 14:44
  So so there's a kind of marketplace in these things which we'll see has a bit of a problem.
• 14:50
  Okay. So SGX is this trusted execution environment.
• 14:55
  And so now you're not trusting us anymore.
• 14:58
  Your code starts off by entering an enclave somehow.
• 15:02
  And this can provide confidentiality and integrity.
• 15:07
  The integrity there checks on all you really running on it on SGX.
• 15:11
  And then then is this you know, it's this really I mean, actually running on this processor.
• 15:15
  And if you can in talking to another processor, is the other processor able to tell you are who you say you are as well?
• 15:21
  So there's a whole bunch of other technology in here,
• 15:24
  but basically you have an enclave code and data and thread support in in this particular where support for this this sort of world.
• 15:33
  So it's an extension to what is already a very complicated instruction set architecture.
• 15:38
  Anyone who's ever read an instruction set architecture book, I think the last one I read all of and understood was a PDP 11.
• 15:48
  The arm is just about double. If you were teaching computer science, you know, processor architecture 1 to 1,
• 15:53
  you might teach from a Hennessy Patterson's fantastic book, which would be about a 32 lectures to get about halfway through.
• 16:00
  And that's when the MIPS processor, which is quite simple compared with any of this.
• 16:03
  So but anyway, so Intel, God bless them, have added this confidentiality and integrity checks for going in and out.
• 16:12
  But also crucially, as I mentioned, the bottom line here is you want your data to be encrypted storage on disk,
• 16:18
  SSD, a lot of the time in transfer open networks over links.
• 16:21
  And now this supports encrypted memory. So if you're sitting there, you've read recent events in this book, but what about the cash?
• 16:30
  Now it's about encrypted RAM, so it's a memory controller which can do encryption and decryption of fetches from RAM.
• 16:36
  Okay. So, so that's, you know, that's,
• 16:39
  that's the sort of first piece of SGX that kind of there's some extra protection and
• 16:45
  there's some magic associated with each and every separate intel processor shipped,
• 16:50
  which does a bit of the keys for doing this. Okay.
• 16:54
  And this is just I really don't have time to go through code examples.
• 16:57
  So this is just, you know, a piece of code that doesn't answer in a piece of code that runs in the enclave
• 17:02
  that gets a message which said the user ship say off disk or off network,
• 17:07
  then that code can safely decrypt, do some processing in the middle, encrypt the output, copy the message to the output, the result buffer and so on.
• 17:16
  And there's an interface to this. There's a sort of enclave enter and exit, but there's also their ingress and egress calls into the system.
• 17:25
  So there's when you construct the enclave in the first place, you need to know your code got there safely and it's done sort of page at a time,
• 17:34
  move the code in there and then at the end of that to say there's an enclave
• 17:39
  measurement process where the CPU can calculate measurement hash and then just say,
• 17:45
  have we got the right code there? Are we talking to the right person?
• 17:49
  And the second piece of this is apart from local attestation, second is remote attestation.
• 17:54
  So we need to just talk about two different enclaves talking to each other and remote attestation.
• 18:00
  So these are those pieces I just skipped over because they're fairly standard crypto protocols for doing that kind of thing.
• 18:06
  If you think in terms of if you ever used to email anyone ever used secure email,
• 18:11
  it's there's no repudiation of who sent this to you and who you are to receive it and so on.
• 18:16
  So that's kind of what you're getting from that. Okay. Hardly anyone ever uses email.
• 18:20
  Very strange. But anyway. Okay, so that's what that's all about.
• 18:25
  There are some interesting limitations which very, very much matter.
• 18:31
  The current one, the top is the amount of memory you get encrypted on.
• 18:35
  The current SGX intel processor is extremely limited.
• 18:38
  You really don't get very much by my standards with the PDP 11,
• 18:42
  a couple of people in a room in here might know the first sort of LSI 11 had about 56 K bytes or usable
• 18:48
  memory and we used to use that for multiple users running version six Unix for log in over Cambridge rings.
• 18:53
  It was fine for K by some memory.
• 18:57
  So in this terribly impoverished world in terms of encrypted memory, you're going to get about 90 meg of encrypted memory.
• 19:06
  And of course everyone's probably used to writing analytics program where you glibly throw some small core application and you go,
• 19:12
  Oh, it doesn't matter.
• 19:13
  I got four gigs on my laptop, and then if that's not enough, I can put 16 gig and I can run it in the cloud and it offered terabytes of whatever.
• 19:21
  And there's also some overheads going in and out of the enclave that are non-trivial, particularly if you exceed the memory and you stop paging.
• 19:27
  There's a massive overhead because you have to software the pages to move them out.
• 19:30
  And so so it's pretty, pretty scary. Okay. So there's a bit in the middle there which we'll come back to.
• 19:36
  But so channel attacks are possible. So never said they weren't.
• 19:41
  But in general, if you're careful about how you do things, they may be quite hard to use or they might have been until recently.
• 19:47
  Okay. So what we done that, we didn't do that.
• 19:51
  That's all. Intel and other folks have done similar things. I mentioned ARM.
• 19:54
  But what we've done is we wanted to put arbitrary applications into this.
• 19:58
  You could take your application to this and call you enter, edit the code,
• 20:01
  put it in, compile it and run it and you'd be you be using the enclave in some way.
• 20:06
  But we said, how about we do arbitrary application support, you know, so we may be running a JVM or dot net or some other support and so on.
• 20:13
  And then we also need to talk to the outside world. So we need to talk to what we have to do, like loading.
• 20:19
  And then we need to talk to file systems, deal with signals, do networking and the process, those bits of code better,
• 20:26
  do the the ingress and egress and the enclave security because they're talking out of the enclave at that point.
• 20:32
  So they have to do the right thing in terms of crypto. So.
• 20:36
  So Peter Slattery and Imperial have built this Linux kernel library to simple arbitrary Linux applications,
• 20:43
  anything that lives in a fairly, fairly standard alpine in its world.
• 20:49
  We'll just run on this. This is kind of cool. So anything, any binary that run an alpine index will run on this Linux kernel library.
• 20:55
  And the idea is you just edit the relevant bits that are kind of library said that it enters and exits
• 20:59
  the enclave and then application running on that is now running in the enclave or external enclave.
• 21:03
  And anything that wants to cool networking or disco goes through the appropriate libraries which do the appropriate crypto in and out.
• 21:11
  If you're sitting there thinking security people, I recognise the room thing yeah but you know networks that crypto is any good had you know
• 21:18
  your disk IO crypto is any good and how do you know Intel's memory encryption is any good.
• 21:24
  Well, you don't. But, you know, you might have gone mobile, checked some of them.
• 21:28
  We have another project which is doing this all in Carmel and we have a little checked stack, so we think that's okay.
• 21:35
  But that will give you network crypto. Okay. You could put that into this world.
• 21:40
  So that's really what's going on there. There's a bunch of other pieces you have to look at or is this very standard consistency stuff.
• 21:47
  And I have to go through it pretty fast because it's background.
• 21:51
  And the idea, though, is you're going to have to deal with your memory management,
• 21:56
  your your system call stubs have to be implemented so that because you can't do an actual system,
• 22:01
  cause you can't do a track in and out of code, because that trap is itself changing privilege level and it's what you're trying to get rid of.
• 22:07
  So try to do that. Okay. So the thing we wanted to do with all of this, to cut to the chase was to do some big data processing.
• 22:16
  So. You could choose lots of different data processing analytics platforms.
• 22:21
  Actually, the first thing the Imperial Folks did with some guys from Germany,
• 22:26
  they had a really nice project where they put Docker containers into SGX.
• 22:30
  That was a clever idea because that put anything containerised potentially into an enclave.
• 22:35
  And as a paper about that, I think in OCI a year and a half ago goes by the name of stone for secure container extension for next year.
• 22:45
  Anyway, so, but then we thought, well, actually that's, that's, that's too general.
• 22:50
  Let's go one less general and let's take a particular data processing platform.
• 22:54
  And the you know, interesting one of choice might be SPARC.
• 22:59
  Hands up if you view SPARC. Who? About three people.
• 23:03
  Anyone use Hadoop? A couple more people, many people who reduce.
• 23:10
  Okay. The same kind of people. Okay. So if you have a lot of data and you want to paralyse and distribute things in a data centre,
• 23:18
  cause there are lots of processes there and lots of racks of processes,
• 23:22
  then these are a fairly starter set of tools that let you do parallel distributed computing over a over a datacenter environment.
• 23:29
  They're not the same tools you would use in an HPC,
• 23:33
  very tightly coupled cluster computing platform where you'd use some PBM style of system, but they're very,
• 23:39
  very widely used and SPARC is kind of SPARC is particularly state of the art in machine learning styles of tasks
• 23:47
  because it has a fairly nice way of dealing with asynchronous and redundancy that actually sort of scales quite well.
• 23:55
  And SPARC, it's usually kind of coupled with R and R is a language package which is it derives from S,
• 24:03
  which is a very, very commonly used statistics package. So there are a lot of good reasons to to take SPARC as an example.
• 24:09
  One of my students who I didn't really supervise, who's way too small and did all his own work,
• 24:15
  he currently works for Microsoft and and as your research and things and he's done this for Hadoop and for SQL Server and for some other things.
• 24:24
  So I think he's you've got a blockchain running in SGX, which is kind of cool.
• 24:28
  But we chose to do this with Spot because in our friends in analytics and machine learning, that was their kind of principal current tool of use.
• 24:36
  You know, people out there might say, Oh, well, actually, you know, I'm using TensorFlow, you know, because I'm a real neural net person.
• 24:42
  That's the tool. Well, we haven't done that,
• 24:43
  but one of the things we're doing with this work is documenting what we have to do so that somebody else could repeat that work.
• 24:50
  You know, just take the runtime for the data processing for the analytics platform and redo it.
• 24:55
  So what's the interesting issue is Spot, which is basically it's kind of still doing a MapReduce style of computation where
• 25:03
  you've got a bunch of data in each node and each node maps a function and reduces that,
• 25:08
  and then you share all the results across all the nodes and then move on to the next step.
• 25:13
  So. So what we want to do is to take that code that maps and and reduce its functions and put that in an enclave and then have
• 25:21
  the data come out of memory because that's where it's going to be is going to be in one of these ads that Spock uses.
• 25:26
  And then in the enclave, be decrypted, have the function mapped over,
• 25:30
  iterate and then move on to the next function and then do that and all these notes in parallel.
• 25:35
  So what S'POP is written in basically has to has means that we have to put a JVM into the enclave.
• 25:43
  So this gets exciting. So, you know, I've said all this, we could map other things into the enclave,
• 25:50
  but we chose to start with spoke with documents in such a way that other people could use it.
• 25:56
  One of the things you might be thinking out there, if you do any large scale machine learning,
• 26:02
  you might be going, well, what about the accelerator hardware that people use?
• 26:05
  So people in. DeepMind and many other places Microsoft anywhere, Facebook, wherever.
• 26:14
  Anyone doing machine learning probably will use a GPU. They might use an FPGA to do acceleration, and this thing is outside of the enclave.
• 26:21
  Of course, you have to communicate with some channel, maybe memory buses or whatever, maybe some network linked to it or some other model.
• 26:29
  But. So there's an issue there. It would be nice if somebody builds an enclave, CPU, an enclave, you know, trust, execution,
• 26:38
  environment extension to TPS, which is Google's essentially tensor matrix multiply roughly a bit more than that.
• 26:47
  There's yeah. Okay. There's a bottom line there as well, which we'll come back to. Okay.
• 26:52
  So, so the idea we have is we looked at Spark and okay, this is cool, but it's very big.
• 26:57
  You've got Spark, which is kind of huge amount of code that does lots of cool things.
• 27:01
  Actually, it kind of maps, functions over things and then and then and does some cool iterating of that.
• 27:07
  And it's not that complicated, but it needs a JVM which has to be put in the and K too, and that's very big.
• 27:13
  So how about we partition this software? So we were on part of it in the end.
• 27:18
  Clay And the all of the functions which need may not be touching sensitive data.
• 27:22
  So we could do that by a mixture of static analysis and runtime analysis, static analysis and say what is touching the data,
• 27:33
  you know, obviously, and then run it and then say what such and but actually you don't need to really do that.
• 27:37
  That's a cool thing here, which is spot is applying a function, right?
• 27:40
  So and that function is being applied.
• 27:42
  If people write code correctly in an enclave and of data that's come off disk or come off HDFC will come off a cash deal,
• 27:50
  come off of an RTD and it's encrypted.
• 27:53
  So it hasn't been decrypted yet. So we don't actually touch it's not sensitive at that point.
• 27:57
  So we don't have to worry about any of these, no less. So we can probably just deal with the very core pieces of of SGX, SPARC.
• 28:07
  So this is just sort of going through that detail. But I don't, again, have time to go through.
• 28:12
  But this is just saying, you know, what has to live inside the NRA is really decrypting into data,
• 28:17
  compute f of what we're, you know, iterating over the input, encrypt the result and so on and just do that.
• 28:24
  Okay. There's two steps in there just to illustrate that.
• 28:30
  And this is just showing a kind of more general partitioning of the components that go on.
• 28:35
  So, again, I don't have time to go through the details of this.
• 28:40
  There's. Movement between different JVM because you could be running multiple instances of spark and so concerns we have to worry about that.
• 28:49
  So that involves not just having encryption of IO two storage and encryption IO to networks, but now we had two encrypted shared memory.
• 28:55
  So that's another thing we have to manage, which is again another weakness of all of this, that sort of this is a house of cards.
• 29:02
  And you can if a security personnel system password, you could pull out any one of those cards and say, but what if you get that wrong?
• 29:07
  There could be a vulnerability there, just like there could have been a vulnerability in,
• 29:11
  you know, the old model, cloud model with the hypervisor and so on.
• 29:15
  Yes, they could, but we could fix this and then we move on. Okay.
• 29:19
  So. Okay. So that's the first part of the talk.
• 29:22
  So we have that all working. As of around just before Christmas, actually.
• 29:28
  And then what happened? I'm going to move on to this topic in a second. But what happened just after Christmas?
• 29:33
  Hands up. Yeah.
• 29:37
  I hear the ghostly voices. Spector, spector, his haunting, you know, the the clouds of Europe and the world.
• 29:43
  And the first thing we did was check that spectre brakes and and some folks had just published a more detailed thing,
• 29:49
  but I think we were the first to go, oh, dear. So this may hopefully get fixed at some point,
• 29:58
  but basically speculative execution in very complicated market architectures like Intel have allows you to do things that happen.
• 30:08
  And what would normally in a sort of sane world would be another thread and would have all of its access control checks in the right way,
• 30:14
  but doesn't in this world. So to use all the resources you have an approach is just in case this branch of code might be useful later.
• 30:22
  You can run it. And the first thing that these very large number of people I don't have time to quote and go through found was,
• 30:28
  oh, you could you could break the userspace operating system boundary.
• 30:31
  This because speculative execution would just go off and start reading OS memory or memory from other processes.
• 30:37
  And but then the speculative execution would end because it was wrong,
• 30:40
  the branch was wrong and will be terminated, in fact be shut down because it had done the wrong thing.
• 30:45
  But there's a side effect. And a side effect is what Intel never claimed to protect against,
• 30:49
  which is any data access that pulls things out of memory into the cache, leaves traces in the cache until the cache is evicted.
• 30:58
  Unless you manually evicted from the cache, they're around for a while. So cache memory, cache, hierarchy,
• 31:02
  you've got a short amount of time where you might be able to read that unless you change all your code to evict things from the cache,
• 31:08
  where then your processor will run ten 1000 times slower, which is kind of just got rid of the cloud having any point whatsoever.
• 31:15
  You're in trouble. And, and so it turns out the same kind of attack works across SGX because basically,
• 31:22
  as I mentioned, the memory encryption decryption happens from RAM into cache memory.
• 31:28
  But you're still subject to the same possible attacks, interestingly enough, on, um.
• 31:34
  Trust zone. It doesn't appear to. And I think what's happened is.
• 31:37
  AAM have a very simple elegant design where when you do spec contracts Houston's branch
• 31:43
  across the crescent boundary it stops and goes no you don't have to do that correctly.
• 31:47
  But it does work across the OS boundary in the arm, which is a bit puzzling.
• 31:51
  So we're kind of okay, you know, there are ways to mitigate this by changing code lots and lots of places and wait for new processes.
• 31:59
  So if you're kind of a data centre, like a typical Facebook data centre with maybe a million cause,
• 32:05
  you know, buying a million new cores is quite expensive, it going to take a while.
• 32:10
  So this stuff is not really ready for hardcore prime time.
• 32:14
  But actually so I should say kind of yes it is,
• 32:17
  because you could always make sure that your application and SPARC runs in SGX and only runs on cause I have no other things running.
• 32:26
  And then you go, well yeah but we, then we don't get the speed that we need.
• 32:29
  Yeah. But if using 100% of the core CPU time anyway, that's okay.
• 32:35
  And then you could argue well then you don't get the cost saving moving for your private data centre and so the cloud.
• 32:39
  But you do because you get the amortising over various different, you know, operational costs and so on.
• 32:44
  So you still get a cheaper thing, but it's you don't get that maxing basically, which is definitely a bit of a negative thing.
• 32:53
  Okay. How am I doing for time? I can't read that clock. Half an hour in.
• 33:01
  Thanks. Perfect. Well, no, but too many slides.
• 33:04
  But you can meet them later and catch up. Okay.
• 33:09
  So in parallel with that,
• 33:12
  which was trying to help people like the NHS or the financial service folks use the cloud in a way that we thought would be secure, a more secure.
• 33:21
  There is no security. There's just, you know, you mitigated these things and then the arms race moves on.
• 33:26
  The parallel that we've had a completely separate line of work, which comes from the opposite, which is distributed analytics.
• 33:34
  So the idea here is instead of moving all the data to the cloud and doing a computation now,
• 33:38
  instead of all these hospitals moving all that data into central data, data, databases and wherever,
• 33:45
  and then maybe copying that securely into the cloud,
• 33:47
  running a secure computation so you get more CPU and then getting the encrypted output back to their doctors, their medics and researchers.
• 33:54
  We said leave the data everywhere and to distribute the code to people.
• 33:59
  This is the opposite approach and it's very old.
• 34:03
  Two patents in distributed computing. Yeah. Move the data to processing or move the processing.
• 34:08
  So the data is kind of classic. You know, of course you could call it hybrids.
• 34:12
  You'll be sitting there thinking, yes, yes, computer science is really good at patents.
• 34:16
  We could do it one way or the other, or we could do a mixture. But I'm going to talk about this extreme.
• 34:20
  And the point of this extreme was that you keep the data at the owners.
• 34:24
  And this is really targeting different classes of data, at least initially.
• 34:28
  We're thinking of your social media data, your health care data on your phone, maybe monitoring your heartbeat,
• 34:33
  your skin conductivity, your temperature, your number of steps you've taken today.
• 34:38
  Why do you need to give that to anyone else ever? Another example,
• 34:42
  I think I'll just quickly go through the poster child example I think comes from a smart metre project by George Synthesis when he was at Microsoft.
• 34:51
  He's now professor at UCLA and for security. But he did this beautiful project which is designing smart metering and never gave the data from the
• 35:00
  metre to the that the reading dataset was never given to the electricity or gas or water provider.
• 35:08
  He would just give them the summary data. Why did they need to know? What the current in and out of your house every 2 seconds is.
• 35:15
  Later. That's complete nonsense, right? They have all kinds of current limiters and fuses and cut outs to stop bad things happening.
• 35:23
  But they want to know what the reading is each month without having to visit your house.
• 35:27
  That's their big cost saving, and they may want to send your metre a price so they will app on your your home hub
• 35:34
  management system could say here's some clever things you could do in the house,
• 35:38
  like not to turn on your dishwasher and washing machine until 4:00 in the morning because then that would be the best price point.
• 35:44
  Okay. And they might want to do that in a clever way. That is huge. But they still don't need to know what you use every 2 seconds or every 2 minutes.
• 35:50
  That's just irrelevant. They need to know summary data, but you might want to record that data all of the time.
• 35:55
  They want to record it so that they maybe, you know, check. So make sure the summary is correct.
• 35:59
  So the sort of poster child here example is, well, what is what is the what does the electricity company want to know?
• 36:05
  That's more fine grained than a one monthly reading per house.
• 36:10
  Not as fine grained as a reading every 2 minutes.
• 36:14
  They might want to know what kind of household you're from so they can work out a profile of pricing to see what your price sensitivity is.
• 36:22
  And also, when we're just about to run out of gas a couple of days back, you know,
• 36:26
  what could they set the price to be to alter the really big consumers price at the busy day, maybe for a certain class of users.
• 36:34
  So they need to know what class of user you are. So how many classes of users might there be?
• 36:40
  You know, how many household types are there?
• 36:41
  So how about we we know that from historical data there could be 16 kinds of domestic houses, maybe sweetie.
• 36:49
  And 16 kinds are characterised by some distribution over the, you know,
• 36:53
  some samples through the week, over the busy minute, the busy hour, the busy day.
• 36:58
  And that is sufficient to sell this house and not that house.
• 37:02
  So they need to acquire the parameters of that model. So we can do that in a decentralised way.
• 37:08
  We can run all kinds of these machine learning algorithms. We already do.
• 37:11
  We run them in the data centre distributed, except that we run them with all the data coming off the local crypto history.
• 37:17
  We can leave the data there, send the code out to everyone, learn the model parameters at each node and share the model parameters.
• 37:24
  Now, you might say even that reveals something about a household.
• 37:27
  Yes, of course it does. And to some extent.
• 37:30
  But you could also down the bottom there, you could share that information, peer to peer, while you build up the model, you build the accuracy.
• 37:38
  So if you all 16 been histogram and you're learning what the different models are that fit in that,
• 37:44
  and you get your accurate model off to some number of iterations,
• 37:46
  you're doing machine learning over this thing and you say, Oh no, that's good enough.
• 37:49
  Now we can ship that to the electricity providers for their cost for their customer base.
• 37:55
  And at no point did you give detailed data to them. Okay.
• 37:59
  So that's sort of distributed. Machine learning and lots of ways you could do that.
• 38:05
  Again, this is really neat because you avoid the whole problem of GDPR.
• 38:09
  So I'm going to go to that. But at no point did you give the data, the raw data.
• 38:12
  20 Well, you, you do have an interesting problem.
• 38:16
  Again, okay, folks have some really good stories on this, which is if you make a decision to change the price for a customer, they might go,
• 38:23
  Why have you changed my price to be that my neighbour got a different price change and you have to explain that it depending on the model complexity,
• 38:29
  it might be quite easy to explain. You might be able to say, well, you know, you have four kids who put in a dishwasher five times a day,
• 38:37
  you know, and you don't have to know that you would feed the price and it would go into the model,
• 38:41
  the data you have in your house, and it would pop up that thing, go, Oh, we can see the model fitted this and then you go.
• 38:48
  Okay. So so we built this crazy distribution analytics platform and there are lots of pieces for this.
• 38:54
  The last bit I want to try and get to is how you do very wide area distributed machine learning.
• 39:00
  So the first piece running SPARC is important because it's very high throughput.
• 39:05
  If you've got a lot of data in a data centre, you have a bunch of nodes in a very large memory footprint,
• 39:10
  ignoring SGX limits, very, you know, multi gigahertz processors, lots of cores, ten gig, even 100 gig, ethane everywhere.
• 39:19
  You've got a bunch of people in smart metres in a home or their smart TV in their home, and you're sharing mobile premises between homes.
• 39:25
  You've got a wide area network and the uplink out of people's home is typically today ADSL in
• 39:32
  90% of the UK is of ADSL is around a megabit uplink it's about 10 million homes on fibre.
• 39:38
  So then the uplinks are a bit faster, but the smaller parameters in the histogram, some values,
• 39:44
  they're not really a lot and you don't have to do it very often because how often do you run that computation?
• 39:48
  How how high throughput is it?
• 39:50
  If you were doing this on people's smartphone and you're trying to learn a model of them as part of a model of lots of people's,
• 39:56
  you know, health response to a sudden drop in temperature and they're going out running.
• 40:00
  And then you might want a feedback, somehow a warning to a collection of people in this thing saying, you know,
• 40:05
  famously, don't go and take the snow because the temperature drop combined with sweat will cause heart attacks.
• 40:11
  A large number I lived in Canada for was this warning you get.
• 40:14
  If you're over a certain age, it's like, you know, get your night, your neighbours, kids to drink, take the snow.
• 40:19
  Okay. So we built this platform called Owl, which is a distributed numerical package basically to start off with, and it's written in a camel.
• 40:28
  And we had a goal for doing this. We have a library operating system. Instead of being written in C, in C++ and being thrown in, it's alcohol.
• 40:34
  Well, this is from a library operating system we have in Cambridge called Mirage, which is a very cool system.
• 40:40
  Now, Camel, which means we don't have a large class of vulnerabilities.
• 40:45
  You don't have to say you might say what a camel y camel is like a variant.
• 40:49
  I mean, why didn't use Haskell or why didn't use something else is because we're Cambridge.
• 40:53
  We use a camel. But, you know, it's you could redo it in 3 minutes in Haskell while no 11 minutes but eshop right so okay.
• 41:03
  So we built all these things in in for doing that. For this reason it was for doing this distributed system.
• 41:09
  And so it's a lot of different applications. We've built a mad amount of code, so a lot of cool people contributing to this out there.
• 41:16
  So it's a brief picture of the the whole architecture of our sort of distribution in parallel analytics with a whole framework for applying functions
• 41:25
  over data in a wide area and various system backend is a lot of people work on this in Cambridge just to say we even got bits that go in browsers,
• 41:34
  we have bits do memory management for types we have this is all, by the way,
• 41:39
  Sam Statman in Oxford does some of this stuff with monads and numerical stuff.
• 41:45
  So there's a, there's some very cool theory people here which we liberally heard their bread, their papers went, yes, good, we can use that.
• 41:54
  Okay. So and we have we can even run code, we can map code down onto GPUs and all kinds of other pieces.
• 42:01
  So we have. You know, we have we have a raise, which doesn't sound very functionally very nice, but we have ways of doing MapReduce over those.
• 42:09
  We have neural nets and we have a way of doing peer to peer neurone so we can train up on your own.
• 42:15
  And we have a poster child. Example of this is learning to recognise faces.
• 42:20
  So we have a neural net running in raspberry PI's running this code with this library operating system matching the dot container and tracing.
• 42:29
  So it's even bullet proof at that level probably. I don't know how good that is.
• 42:34
  And then we're training on faces and we share all these parameters in this neurone about
• 42:37
  faces between lots and lots of little tiny notes that learn about three faces in this house.
• 42:41
  Three different faces in the house. What are features that make faces? And then you get a better model.
• 42:45
  And then you go, Oh, this is somebody who lives in this house. Oh, we don't recognise that is a face, but we don't know who it is.
• 42:51
  So. Right, so that's a, that's an application we have, it's an example of why would you want privacy and so on.
• 42:58
  So we skip that code again. You don't need to see the code if you want to use this.
• 43:02
  This is all downloadable as well. So I wanted to skip to now you're doing a distributed computation and there's this
• 43:11
  problem which is your you need to if you're iterating over data in our grand vision.
• 43:17
  Right. Is there say 35 million homes in the UK. Imagine every home has a Raspberry Pi or whatever your favourite small computer as a home hub.
• 43:25
  You know, we just send it to people in the post and you know,
• 43:28
  they just plug it in and forget about it and it's just hidden inside something they bought anyway.
• 43:32
  Right. And it says, you know, approve. Does this will look after your personal health data and we'll never send it to
• 43:37
  anyone else unless you prove and it might back it up encrypted to your GP's,
• 43:41
  you know, cloud service but they won't be able to look it without your permission. That'll be a sort of model of the world.
• 43:46
  So now you want to learn about things on that data,
• 43:49
  over 35 million nodes and you do an iteration and you need to do a sort of next step of the iteration.
• 43:55
  So if you're doing a classic MapReduce, you kind of everyone does this bit of the data and then they do this huge exchange of data.
• 44:03
  And you need to synchronise everything, don't you? Wouldn't you have like ten square messages going everywhere at this point?
• 44:09
  This is a problem for training units in a data centre.
• 44:13
  If you paralyse training neural nets over data,
• 44:15
  you split all your face data over lots of big nodes and data centre and you run your tensorflow for it.
• 44:20
  Then this is huge. Exchange rate, you go through the next step of the operation, the output comes out and you look at the you know,
• 44:27
  you may be looking at gradients or whichever thing you use for the feedback into the training, but into Sherritt, all with the other nodes.
• 44:33
  And you've got an N Square message problem. So, so this is the kind of piece of what we had to start thinking about,
• 44:39
  because now we're not in the luxury of a data centre where that won't scale and square, but at scale, certainly one scale, 35 million.
• 44:45
  But you don't have 35 and you might have a you might have 100,000 cores in a data centre is
• 44:49
  still 100,000 squared is not a good number of messages for every step of the iteration.
• 44:54
  So what do you do? So you need to throw away some stuff.
• 44:57
  So, so the classic sort of barrier synchronisation step in a kind of Hadoop is not going to work.
• 45:04
  So you can come up with other ways of doing this classic one if you want to see that.
• 45:09
  I think my the best read paper is probably hog wild where you have parameter servers that actually you send stuff to one point.
• 45:16
  So you have messages rather than square and they share it out.
• 45:19
  But there's more recent work where people have done other things you can do and you could run a synchronously.
• 45:23
  Why could you not run asynchronously in training? Well, it depends on the learning, but most algorithms might be gradient descent.
• 45:29
  Stochastic gradient descent will still converge. Even if you don't do everything at the same rate.
• 45:36
  You can be asynchronous even you can lose data if you do more iterations more than you lose accuracy by losing data.
• 45:46
  Then maybe you speed up the overall computation to get to the accuracy level you want your your training to run out.
• 45:53
  So. So that's kind of the theory behind what we built in this, where we relax all these things and decompose synchronous.
• 46:01
  Basically what we end up with. Right, is probabilistic.
• 46:06
  And there's one club. This is all name checked the right people.
• 46:10
  And hopefully there's one fantastically clever bit in this which is actually is faster and more accurate.
• 46:16
  But this is this is by Liang Wang, who's a post-doc in Cambridge.
• 46:19
  He came from Helsinki with a very smart Ph.D. and started working in mobile networks.
• 46:25
  And he looks at this stuff. And right now what you need to do is this, and you need to essentially discard results statistically.
• 46:32
  And you know what?
• 46:33
  If you if your sampling algorithm is correct, then the system can be made to converge arbitrarily as good as not losing those results.
• 46:43
  So you look at the accuracy you're getting from different nodes, giving you data,
• 46:47
  the output, the output parameters you normally centre, the whole qual parameter server.
• 46:52
  And then you can do really, really well with this. We haven't tried this with 35 million homes, so yet that's some ways off.
• 47:01
  We have tried it, you know, in a small systems with a thousand nodes and, you know,
• 47:05
  little test beds and so on and you're scaling stuff you can sort of extrapolate with a thousand is a large number, I think probably.
• 47:14
  Yeah. So we have this cunning sampling primitive, which is kind of a clever way to hold a function, so just an implementation trick and so on.
• 47:21
  So we, we've sort of discovered something we think I thought this was fantastically new.
• 47:26
  And then I examined a PhD on distributed neural net training, an imperial firm, Peggy Kerr.
• 47:34
  Remember she now Microsoft in a health true machine learning group. Very, very cool.
• 47:38
  And she'd come up with a very similar diff, slightly different angle with similar trait about two years before us.
• 47:43
  So we're like, Yeah, okay, that's good, that's good. Somebody else. Reproducibility research is a good thing.
• 47:49
  Okay. So and the tricks you can play in here with sort of the whole trade off again,
• 47:54
  I don't have time to go through these numbers but so you can change the step functions in training.
• 48:02
  Scalability is good, robustness is good and convergence is good and so on.
• 48:06
  And this is just sort of the bottom line is trying out this with some test set data sets that people use as standards in training these systems.
• 48:16
  If you're this is this is kind of scary actually how good this is one years coding by Liang
• 48:21
  and five other people and some other contributors around the world and the the green is sort
• 48:28
  of inference time for for you know training up in section V three for example is a classic
• 48:33
  versus a TensorFlow and Cafe two doing the same thing and we're in the same ballpark figure.
• 48:38
  And this is written in a camel.
• 48:39
  And it's, you know, it's very small, like numbers of lines of code, and it's really high level and readable and blah, blah, blah.
• 48:45
  There's all kind of a good thing. Okay.
• 48:48
  So that's kind of the end of my slides.
• 48:51
  Apologies. I really I didn't have a long enough train ride this morning to delete sort of the old joke.
• 48:58
  Half of them. I shouldn't have that. Please do email me if you want to follow up on any of the pieces here.
• 49:03
  There's very specific kind of acknowledgements.
• 49:07
  This is this is other people's lives or other people's work. I'm kind of a person who runs around trying to get the money from the funding agencies.
• 49:14
  You know, three goes, you get it usually. And the important groups, like I mentioned, is the large scale Distributed Systems Group run by Peter Pitts,
• 49:25
  a professor, Imperial College and founder computing. If you want to do systems work, absolutely great group.
• 49:31
  They have loads and loads of good people there and they do this kind of stuff.
• 49:35
  And then we in Cambridge we have an amount of petty, rich, malattia, nag Wang and a host of other people.
• 49:43
  This project was the spark putting in our into and Java into SGX is funded by the Turing and actually the main interest upon a Turing the
• 49:54
  defence people because they want to be able to do analytics and surveillance data and be able to prove that they're the wrong people.
• 50:01
  Didn't see the data or the people didn't see the wrong data.
• 50:04
  So they want to have a get out of jail card because they're now under the law, which is kind of interesting.
• 50:10
  But it's the same kind of motive, which is to be squeaky clean as the health care and the financial data.
• 50:15
  Right. So they have centralised all the data. Obviously, the other side here is data boxes and APC funded project.
• 50:21
  And the other partners in that I mention is Hamid had AIDS and Imperial and some folks at Nottingham and I didn't mention the downside of that.
• 50:30
  Okay. So there's a downside of the Spark's SGX stuff, which is the Spectre speculative attack plus side channels,
• 50:39
  which there are mitigations for, but they're problems.
• 50:41
  The downside of the data box stuff is we really, really haven't got a good solution to the how much can you learn by observing the mobile updates?
• 50:53
  Now, if you've read about machine learning, and particularly in deep learning,
• 50:57
  there are very clever people who've worked on how much can you infer from a trained classifier and then fix that problem for that one instance?
• 51:05
  But if you're looking at the thing being trained, you can probably infer most anything.
• 51:10
  And so there are decentralised attacks when all a decentralised approach,
• 51:15
  somebody could just basically join the network in a peer to peer system, get all the updates and then infer all the data pretty accurately.
• 51:21
  So we don't have an answer for that. That's like a well, okay.
• 51:25
  So THQ can infer how much electricity use every 2 minutes.
• 51:29
  On the other hand, you know, I suppose there, you know, in the financial side that's not a good solution,
• 51:34
  but the financial side we think is over in this space anyway. So it's not it's not the threat threatening,
• 51:38
  but in the middle is probably healthcare data where it starts out with a lot of it being centralised in hospital data records.
• 51:44
  But more and more, we're moving into this evidence based medicine where you carry devices and they monitor stuff about your behaviour and so on.
• 51:51
  And then that is the on the,
• 51:53
  on the data book side and then you might care about people inferencing things about your health which may not be public matters.
• 52:01
  And so, okay, so that's about it for my talk and I guess any questions time.
• 52:17
  Look, let me boot things off. So we were briefly before lunch discussing kind of multi-agent systems and actually the particularly the OWL framework,
• 52:25
  they had a very multi-agent system. Z feel about it, is that right?
• 52:29
  Or A That's a very good observation, which I completely not thought of.
• 52:34
  That's not how we think of it. But I write we should probably.
• 52:38
  That's a good point. Yeah. Yeah.
• 52:40
  Because it's basically we've moved to a set of asynchronous nodes which are distinctly messages or about what they've learned for parameters,
• 52:48
  for a model of what they've learned, not the data they've acquired.
• 52:51
  And that could start to look very multi agencies to be felt very much along those lines.
• 52:55
  Yeah, but it starts from a traditional training, you know, ensuring that we're doing linear regression of a, you know,
• 53:02
  multi dimensional thing and then we do this and then to make it work in a large scale, we go async and I guess we end up in the same kind of space.
• 53:10
  We're not we haven't thought about coming from another space which would be running a, you know, a probabilistic programming approach as well,
• 53:17
  which would be another thing I think would be to inject that into that just decentralise architecture would be fun.
• 53:23
  So there's probably some confluence of that stuff architecturally, which would be interesting.
• 53:28
  Yeah, no, it's really interesting. Thank you. I will take that back home.
• 53:35
  You mentioned the distributed energy fixes an interesting idea that the data was stay at the source.
• 53:41
  So. So there's a range of techniques being proposed in the research.
• 53:48
  Community. Thanks for privacy conclusion.
• 53:52
  What would be your judgement? How far you are from?
• 53:58
  Well. So in the. There's a separate, slightly, slightly different thing, which is, well,
• 54:04
  sort of homomorphic encryption would be a lovely it's kind of like cold fusion.
• 54:09
  I mean, that's not fair. It's like it's like not cuttlefish is like normal fusion.
• 54:13
  It's sort of we get it's a bit more like it's little nearer than quantum computing, practical quantum computing.
• 54:18
  But to be fair, it's demonstrable and it's the most reliable, very simple functions.
• 54:22
  And that would be really cool because that would be much better than relying on unbelievably complex extensions.
• 54:28
  Intel do. So you have homophily encrypted data and one of the crypto functions over the data and relatively simple code getting it to go fast.
• 54:38
  Charlie is the big challenge, but people are actually making. So I think it's probably fair to compare it with the sort of normal fusion where
• 54:43
  they're actually visible progress in plausible directions and in specific functions.
• 54:48
  I've seen some really cool results there. So that's definitely it's a good research direction in cryptography and math.
• 54:54
  If you're in that space, super fast algorithms in that space,
• 54:58
  the differential privacy might be a technique we throw at the decentralised exchange of things where we might put a bounds around what we exchange to
• 55:07
  make sure that a certain number of peers get the data for the models and the
• 55:13
  data is checked against an epsilon to make sure it's differentially private.
• 55:17
  It doesn't reveal things about the raw data. The model parameters are coming from.
• 55:21
  I, i we'd have to think about, you know, what the relationship between model promise parameter inferring is, but other people have done some of that.
• 55:29
  So that would definitely be a thing.
• 55:31
  And then we were talking earlier about when you federate data from multiple agencies into a central system before you even get it.
• 55:39
  In the central system, a lot of cases differentially private data might be good in it, good enough for a lot of problems.
• 55:45
  We're trying to do infancy of some health care thing.
• 55:48
  You know, I sort of jokingly said, you know, maybe use of ozone in swimming pools causes asthma,
• 55:53
  you know, so you do a map of where asthma attacks show up in hospitals.
• 55:57
  You do a map of swimming pools where they use ozone instead of chlorine for for, you know, cleaning the pool.
• 56:02
  And then you do a correlation and you can do, you know, location based differential privacy pretty well normalised to the population distribution.
• 56:10
  And you still have enough cases of these. I mean, I you know, I don't believe that's an actual causal link,
• 56:15
  but I'm just giving you as a hypothetical example would be a question you might ask and it could
• 56:19
  be done securely with differential privacy and you don't need any of this complicated mechanism.
• 56:23
  The data would still be staying in privately owned, secure databases and only query results that met this.
• 56:29
  This limit would be a good exchange.
• 56:32
  So I think that's a technique and apply lots of places and is very practical and well described in the literature.
• 56:38
  Um, yeah. Okay. Next question.
• 56:43
  It's one of their. Oh. There's a microphone.
• 56:47
  Yeah. You seem to have talked a lot about the confidentiality side and also in the distributed bond availability.
• 56:56
  But in terms of integrity, you mentioned integrity of data, the encryption level, but what about injection of data sort of Byzantine problems?
• 57:05
  Because if you're going to do smart metering and there's money involved, can I get somebody else's bill changed?
• 57:11
  Can I actually inject bad data into this as a great point and I truth in advertising,
• 57:19
  we don't have a fix for that in our decentralised architecture or in a peer to peer.
• 57:23
  Well, we're subject to all the attacks that are being demonstrated time and again on those worlds where money's involved, I suppose.
• 57:32
  I suppose there could be some way of carrying signature data through their mobile inference that sort of signs the,
• 57:40
  the, the model and says this was derived in some way from something.
• 57:43
  So the metre companies still own the audit trail without getting the detail result.
• 57:48
  But I don't I don't know that would that's completely fair criticism in that space we have to to tackle that
• 57:55
  somehow I don't you know we could try to sort of have a conversation about it or if you've got a solution,
• 58:01
  I'd love to hear one, but I'd say. Brilliant.
• 58:04
  Thanks. Thanks. You? No, it's a completely fair point. Yeah.
• 58:07
  And it's always a problem of these decentralised systems that they have some plus point or some minus side.
• 58:12
  That's one of the big ones. Yep. Injecting fake data with.
• 58:16
  Yeah. Yeah. For fun and profit. Good point.
• 58:20
  There was a question up there. Right over there. Thanks for a very practical question, I suppose.
• 58:30
  Have you seen beginning your lecture to SGX?
• 58:33
  Have you seen that be made available on the likes of IWC or these sorts of large cloud providers?
• 58:41
  SGX on IS on Azure as confidential cloud computing, and I haven't managed to yet to talk to the people that do it,
• 58:51
  but I believe IWC will have it, you know, in the next minute or two.
• 58:56
  But, but of course we have this problem with the Spectre attack.
• 59:00
  I believe the way that Asia deals with that is they have only ported their tools.
• 59:06
  They want you to use the confidential cloud that they have, which is Hadoop and SQL Server.
• 59:11
  And so therefore they can do the they can handcraft the mitigations for the attacks.
• 59:15
  And I think that that they're really good, that group actually.
• 59:19
  So I suspect that they've got that right.
• 59:21
  But that means you're sort of in some sense is stuck with the tools they've done, but that they're pretty okay tools for some things.
• 59:28
  So I think generally deploying SGX as a sort of extra service for users to just use, firstly,
• 59:34
  you need some newer processes and they're generally not in the high performance yet.
• 59:39
  And secondly, the memory limit probably will kill a lot of your customer base unless somebody is very clever.
• 59:47
  And thirdly, now we're just sort of worried about, oh, there's a new version of it's supposed to be out anyway,
• 59:51
  which may mitigate the Spectre attack better and gets rid of a large part of the memory limit problem.
• 59:56
  So I could imagine really big cloud provider would just be, you know, having lots of conversations with Intel and maybe even saying,
• 1:00:02
  oh, we're having a conversation with Andy at the same time, you know? But yeah, it's a good question.
• 1:00:07
  But I think if you want to use this, you can go to Azure.
• 1:00:10
  And they have a couple of things that I think are pretty, pretty solid.
• 1:00:18
  Other questions. Okay.
• 1:00:24
  Well, everybody, let's thank our speaking and thank you.