 My name is Ralph. I'm going to present a Kind of evening and night project of mine to you, which we call all mogo we're trying to design a Something like a cryptographically secure social network that can also be used as a private data storage that can be used as a chat system and That's designed for long-term archiving If there's an if there are any questions, please don't don't hesitate to interrupt Unfortunately, I'm not going to do a demo in the presentation. I can show you some of the prototypes that we have After the after the presentation, but I didn't feel it was it was right to show it here on stage already So who who is all mogo? It's basically a friend of mine and me the right ones me Ali is an Entrepreneur who sold his first software company end of the 90s and That was in in he was actually designing a hospital information system so he was handling clinical information and Sold that to a number of hospitals and then sold his company And has now other projects on his agenda and I'm in my public life I'm a I Lead a team of embedded software engineers and one of the large companies But when the kids are in bed, I'm trying to work on that project. Additionally, we have a few designers and Programmers with us that that help us implementing everything. But as I said, it's in an early stage So what do we aim at with all mogo? one thing that's on our agenda is to really put back the The users in control of their data. I don't know if you've been at the Privacy international talk. I I seen the speaker here. I think in the in the in the audience actually That was a very interesting talk about how companies exploit your data We would like to provide a platform where you can actually see what kind of data is visible by whom so that's That's actually the second point and provide a system where everybody can opt in or opt out in the usage of personalized data And offer transparent feedback on who can see what kind of data and That brings me to the other point. It's I don't think it it makes total sense to keep Everything in private but the border between Private life and public life should be clearly delineated So if I don't care in a certain circumstance about other people seeing my data or using my data That's fine. It's just about me knowing who is going to be acting on on my data Should be user friendly should have open interfaces to make the access to data and the administration of access rights easy One of the business aspects of it is that we that we want to offer companies a way of storing personalized data in accordance with the upcoming Legislation that means we're trying to store personalized data as your data So if a company we offer an interface that if a company acquires data that's Personally belonging to you according to the legislation It will be stored as your data and you can ultimately control who has access the company can give itself access to it while storing it but you can withdraw at any time the access to that data set and To provide a universal distributed data storage system With maximum security and resilience to attacks So what would interest me in the end is if the ideas I'm going to present you if if you think these ideas are valid and If if if you have maybe some some opinion on on what we're doing So let me introduce a little bit the problem setting I guess that's clear to everybody here But I still would like to elaborate a little bit more on what we think the problem is So first problem do we actually have control over our digital self and I'm not talking about the data that Maybe your car collects while you're driving, but actually the data you think you're in control of so that's me And if I want to share something pictures anything texts messages with my friends then personally Even as a technical expert I would think okay the data I send it to somebody so this somebody should be able to see it But usually I think I think most people don't really recognize that the data is also seen by others especially by the Infrastructure that you're using so obviously if you share some images via some system like Facebook or even by email or anything the infrastructure is a vital part of it And most people that are not so technically deep into the topic Don't recognize that that's that's one of the problem that to solve that There's a very simple prerequisite which would be that If you share your data with somebody you put trust in that person and that's okay You trust persons because you know them or you think they they are friends and they can misuse that trust or they can fulfill that trust That is something that we have been in the evolution be be like willing to learn how to cope with that But the problem is that the infrastructure you shouldn't be you shouldn't be forced to trust the infrastructure The infrastructure should actually prove that it's that it's secure and one very simple thing to do of course is in this case Complete client-side encryption if you send an encrypted email doesn't matter what the infrastructure does with it It will just be visible by the recipient at least if you can if you can trust the cryptographic algorithms other measures would be possible you could also scramble your data in some way or Make small packages of large data sets if you even worry about the fact that the size of the data could reveal something about the content of the data Apparently client-side encryption is something very simple to do but it's something seldomly done in in in large-scale systems for example, these these are the top 10 security risks in cloud computing as determined by a study from the European European network and information Security agency which you can download from there from their page actually the report and of these top 10 Issues in cloud computing which is loss of governance because the service providers in in charge of the security Lock in because you use proprietary systems that you can't where you can't move your data freely around Isolation failure that some other people can actually look at your data and things like that of all these 10 issues At least these four that I marked in orange are the ones that can be completely solved by client-side encryption while the other four that I marked are significantly reduced Just if you do encryption on the client side, which is actually a very simple thing to do in my opinion Just keep this this this in mind The other thing that normal users struggle with an I occasionally struggle with is if you do client-side encryption and let's say you use GPG or any kind of encryption system for your emailing It's still complicated. I mean definitely you have to use a passphrase for your private key That's that's obvious because otherwise the private key will be Very very vulnerable if you use the passphrase Well, I have forgotten mine quite a few times. I don't know how you cope with it. Some people write it down It's not actually the best thing to do, right? The other thing is that many people use a key that's valid for an indefinite amount of time. That's also not something Something something reasonable to do Key renewal and key revocation should be an essential part of the system these systems support it But in fact, I don't think many people have been using it And then if if you implement the cryptographic system, of course There's all these cryptographic pitfalls that you might step in where you have things that you didn't consider or that might not have been Publicly known at the time when you design the system, which is should you use authenticated encryption? I guess everybody uses authenticated encryption nowadays, although GPG does an individual signature afterwards You should also not you should also if possible not use a single single key pair for signing and encryption because you might be Vulnerable to some kind of oracle attacks and all these things that the the end user shouldn't actually be worrying about So one thing we try to do we try to think is there an alternative to passphrases especially if you want to distribute your private key among many devices and You want to still keep it safe on many devices and if you want to be able to employ an infrastructure to actually exchange it Between these devices and an infrastructure other than copying it on a USB stick and doing it yourself One of the ideas that we that we followed is well You could still you could split up the information in in your key in two parts by using If you have it available a cryptographically secure random number sequence If you would Soar that you would get basically two two sequences one is the original Sequence of random numbers. The other one is just the private key Exhausted by these random numbers if the random number sequence is unique and is Cryptographically secure then of course you you destroyed the information in Each single part of these these these results there so you could Share one part Safely if the other part is not known so if you keep one part on your system and you send out the other one To an infrastructure that keeps track of it That could help in reducing The the passphrase problem because the second system could then do some kind of Authentication against the password or passphrase of yours and if you actually lose that you would still be able to recover the key I know there are other mechanisms of key recovery if if you shared the key or if you shared information about the key between Between many persons But that's not the approach we would like to take And of course if if you're designing a client for the average user then the client system should should take care of all the complicated things like Renew intervals keeping track of your old keys to be able to restore the old encrypted information and also use every now and then modified algorithms with different key lengths with Updated block lengths and and and so on Another another problem that most people I don't think are not aware of is that encryption alone doesn't suffice to take Control of your your private data. Let's assume. I've taken an image And I would like to share that what what do I normally do? Maybe I send it by email to a friend of mine Maybe I send it via chat system Maybe I publish it even on the social network if I think that that image can be seen by everybody I don't care if if Facebook runs its algorithms against that image I can be free to share it and then maybe I didn't switch off the the iCloud synchronization And it's even it's even copied to another server the the problem with that is Normally, I would like if this is happening Singularly, I would maybe remember okay with whom I shared that information But normally I would say that people are not really in control because the data They're actually sharing is copied arbitrarily if you send an email. It's copied as an attachment if You if you send it by the chat system is copied into the chat system is copied to iCloud It's copied everywhere because it's digital information and copying is cheap So once you send it out actually that access has been granted you have no real record of The fact that you granted somebody access to that image to that particular image You cannot withdraw that access right because that information has already been sent to somebody else and So I would I would call it that the process of sharing is actually completely out of control Because we arbitrarily copy data when I think about life in my In my in the business. I'm doing during daytime then is it's the same thing people copy things on network drives They copied in different versions then they send it via email They put it on the cloud system and so on and so forth and nobody actually has track of where this information is being distributed So my opinion is that if you want to properly Bring data governance back to the owner of these data sets You you would have to first of all design a system where you can Grant and withdraw access rights, of course that that's clear if somebody has read access to your data This person is free to to download your data and then distribute it again It might not be legal if it's a company But of course you cannot prevent somebody from doing that But you could at least archive the fact that you gave somebody access and if that person hasn't access it yet Withdrawing the access would also suffice to make sure that data is not being distributed out of your control The second point is all these access rights with whom you shared information They need to be made transparent to the owner of the data, which is you If you want to achieve that then The access rights they should be connected to the data object and the data object needs to be a Singularity it shouldn't be copied. There should be a unique ID describing that data object a unique URL actually and you shouldn't share it by I called it sharing by value You should share it by reference actually you should just share that document URL There's a number of of systems out there Let's say for example mega that provides something like that They provide a cloud storage system, which is client-side encrypted and you can share URLs to the to the to the data stored in there Still The system I'm describing here is a little bit different in that it's not only designed to share large large data objects And the last point I already mentioned with the withdrawal of access rights Data obviously will not be deleted by anybody who copied it But it might state the fact that usage of this data from that point on might be illegal, which might be An advantage if if you're talking about data That was provided by by a company or used by a company That brings me to something that has been mentioned all over the conference as well The a new legislation that will be active from May next year. I think The European General Data Protection Rules as opposed to the US where the equivalence of these rules. I think had been Cancelled by the Trump administration in Europe. This will this will become the become law first thing is a right to be forgotten You you have the right if this is data. That's personally assigned to you. You have the right to request its deletion You should you you also have the right to request your data from a company in In a readable format. So not just the binaries actually it stated that you should be able to get it in a human readable form This is the the right to data portability. That's mentioned here on the slide Systems should be designed that they protect data By design and by default there should be no hidden Secret trap doors that you that you have to enable in order to to to secure a data They should be as a default setting Beactive and Actually, there will be I don't know if in practice, but in theory high fines will be that will be assigned to Companies that not that not that do not comply to these rules so that can be up to 4% of the annual turnover Which is I think a significant amount so again Before I I get into the system in more detail our vision would be that there is an open platform for all of your data where Data maybe even from your car is just not going to a company server, but it's actually going to to to the system That we call all logo which should be an open platform Should be independent of its source if you have a variable It shouldn't send the data to the company that produced a variable It should actually send the data to you or to a system where you can administer this data This platform should should allow you to share and also withdraw The rights to to for somebody else to read it so that you can regain The power over your data It should provide an owner URL for each data element made be just a GPS location From your GPS tracker made be an email made be an image or a complete movie And the system should be designed again With high security and high resilience against the text I'm not speaking about DDS or something like that which is clear That you should have some resilience against it But really a system where an attacker would have to gain control over most parts of the system to actually gain useful information Okay, so let's talk a bit about the the the concepts that we designed into the system One core concept is what we call mogos or mogo is a Artificial word, but we we like the idea about each data man being called a mogo and living in the in the all mogo So an encrypted data entity made be smaller large is called mogo And it can be as I said a picture or document could be a small comment on somebody else's mogo Which would then actually comprise it a chat or some kind of feedback system as you know it from from social networks It could be personalized data of the user In his role as owner or in her role of as owner that was created by a third party For example, as I said GPS tracking or the like Or it could just be an empty container where you like to collect other mogos in there Each mogo has a unique URL called the mogo ID Mogos are invariant And they're encrypted using the standard hybrid encryption scheme Why are they invariant? Think about a system where you would actually like to share your personal data share it with companies Maybe to gain some benefits or anything else If you want to have somebody relying on the data that you store there, you shouldn't be able to change it You should be able to delete it. You should be able to store it You should be able to deliver a new version But a single version at a single point in time should be immutable invariant And the general structure would be that mogos can link to other mogos You could call that child mogos, but actually it's not building a hierarchy It's just a directed a directed graph which potentially is cyclic So you have mogos that link to other mogos and actually the the process of today's Sending around data would just be the process of sharing this mogos somebody the process of commenting or sending a video reply or Posting a comment on a social network site that would just map to a new link from one mogo to another mogo As is the case with hybrid encryption with with standard hybrid encryption schemes and not Not I'm not speaking about those multi-user public-private key systems where you actually just need a Single key for encryption, but I'm talking about the standard hybrid encryption schemes Each user that may access a mogo, which is encrypted Of course need its own version of the encrypted symmetric key that was used for the hybrid encryption And that's the point I mentioned the space where all mogos live is called all mogo all right Why do we think this is kind of a Novel idea or novel aspect to what what is out there on the market? I think the novelty is if you if you think about Data just being connected as a directed graph You can map many of the current applications to this kind of data structure a private a File system that you store in And the private network storage a file system is a hierarchy a hierarchy is a subset of a directed graph So you can map the file system to all mogo you can just store the complete file system to all mogo, but then You you can also make sure that only you have access to that So that would be your private cloud if you if you may a private data storage consists of mogos only accessible by one user That's you If you want to share it you can just Append the number of Encrypted keys for other users and only those who have a key of course can access the data If you think about a chat system a chat system in the standard WhatsApp or messenger case. It's just one message after the other that could be a parent mogo and just Different child mogos underneath that So in the in the prototype system that we have as an app You just choose how to how to display for example such a mogo hierarchy If you say, ah, this is a chat Then you just tell the system to display it in the typical chat form if you if you say it's not It's not a chat It's actually a gallery of images that I created then it should be displayed as a gallery of images Doesn't doesn't matter for the application It's just how you want to look at it if you think about a chat in the reddit Sense where you can actually comment on comments and then a comment on comments further up in the hierarchy that can also be Realized with that kind of linkage And if you think about social network there you normally post something and people give their feedback that's also easy to store in that kind of system and When you think about designing a user interface for that, I know I'm not going to show it here in the presentation I'm happy to share the ideas of the user interface with you after the talk because actually the user interface is currently not connected to the Cryptographically secure core of a mogo. It's just connected to a test server just to see how we can how we can Realize the user interactions the user interactions are very simple You want to share withdraw shares or link mode of mogos to other links and you can actually Fulfill all these these use cases that I that I shown on this slide. So you just need to Slide your mogo on your app to to a person and it'll be shared with that person. You can just Remove a person from a mogo and it will not be shared any longer with that person So that's a very very easy very easy interaction system Okay Let's talk a bit about the programmatic Structure, I know it might not be readable that well, but I'm going through it So what are the components of that system? So that's the person of course who? knows but may also occasionally forget his or her Pathphrase and This person is allowed to access parts of the omogo though the parts where he actually has or she has in this case It's me Has the the appropriate appropriate rights then you have the different user interface user device devices and user devices You can store a device dependent version of the private key we I've shown this Method of splitting the private key into several parts You could do that Individually for each device that you have it would still resemble the same private key but if somebody steals the device and tries to Reconstruct the private key you could explicitly in the system Withdraw the access rights for that single device that you have here So it stores the device dependent version or part of the private key. It may also contain a cache of downloaded mogus for Performance reasons and then you have three types of servers that don't have to be hosted by By us they could be hosted by anybody one is the actual authorization server where all the profiles and Second parts of the keys are stored This one is responsible for authentication of the user because the As I said if you split the private key and distributed over the network infrastructure, you can't Use that private key to actually certify or authenticate against the system So you need to do another authentication process We have the the indexing server which is the directory structure Where all the links are stored the actual data content is not being stored But the index server contains all the URLs for all the mogus and if you want to access the actual data set You get a small small file from the index server That just tells you from which of the storage servers you need to recover what part of of the file So we also additionally split a file in several packets distribute these packets over different different storage Servers and even use a different ID on the storage service So you'll have a you'll have a certificate for all for each storage server that you're actually accessing that Certificate is not linked to your actual identity So in the end if somebody gets control over the of the storage server That person will not be able to reconstruct what kind of data We actually own there and would not be able to derive from the amount of data or the all Any kind of metadata or the the size of individual files what types these files actually contain So on the index server you reference a mogu using a URL that's composed of the index server name and a UUID for the mogu nothing more And what is stored with each mogu is a timestamp so that can actually order them in in consecutive order and the ownership Is marked inside what's possible is that you store additional metadata? But we're not quite sure about how far we go So if you put file name in there that would be vulnerable, I guess Yeah, but if you if you think it's it's it's not a problem you could add this So we have additional metadata support if needed Especially with file names you would I have to you would like to sort after the file name as well So then it needs to be indexed on the database for retrieval and that makes it so it's pretty much Open then if you open that kind of metadata To to to the server if somebody would gain control of that server these names would be visible They would not be transferred necessarily, but they would be visible on the server So so one point that we also try to make is we try to design a system where the Provider of the services doesn't know doesn't know anything about the data being stored if you store file names It's an issue. We're internally discussing actually Okay, the authentication protocol Just a quick wrap up. That's a variant a simplified variant of Kerberos Where you send an encrypted authentication request that contains your username and password Which is encrypted by a key that you know from the so basically with the certificate You got from the authentication server. Of course, that's not safe. That's only safe if you pin The root certificate for your infrastructure. Otherwise, you'd be Probably experiencing man in the middle of text What you get as a response is The second part of your private key in clear text and then an encrypted session key encrypted with your public certificate and an encrypted session certificate that states all the Identities under which you're known to the indexing server So the indexing server also doesn't know your new user name It just knows a number of identities that own a number of mogos and from the authentication server You just get a certificate stating which identities you are allowed to see Okay So that's another point that I'll quickly mention the authentication server Knows your nose and uses your username. It maps that username to a number of identities And different identities can be used for different purposes if you think the information is not so Neat doesn't have to be so secure and you'd like to like to share with a whole bunch of people you could also think about giving a number of people the same private public key pair Which reduces cryptographic Security quite a bit, but if it's a trustworthy group then might be a possibility. You still have device and person independent or person dependent Private key parts because you split it in different ways using different one-time pets The indexing server just uses the identities that have been given by the authentication server It doesn't really have to verify that you're allowed to access Mogos it needs to verify that you're allowed to Store new mogos or that you're allowed to delete mogos, but the actual content is still encrypted so even if you gain access to the indexing server you wouldn't be able to read out information and Last not least the storage server uses again other identities the idea behind that is The storage will actually create most of the Cost in the system because that's the actual data being stored So what we are thinking about is handing out like one-time tickets. So for example, I Request an identity a certificate for let's say 50 terabytes over 10 years I pay that in a single sum and for 10 years that amount of data will be stored there And if I don't extend that contract, it'll just be deleted. Nobody can use it anyways And with these with these identities, I just I just mark my right to store data on the storage server I don't give any connection to who actually stored data there and what kind of data is that? So the storage server doesn't know to which mogos this data actually belongs Yeah, that's just the storage protocol. I think I already explained it so in the beginning you you authenticate against the authentication server if You want to store for example a larger file such as a movie you would you would Split that in different parts that could potentially go to different storage server using different storage identities and you would Authenticate yourself against the storage server using your storage identity would store the data packets you would receive a URL How you can retrieve the data from the storage server that URL is actually not protected So anybody could read that URL although it doesn't contain Useful data because everything is encrypted and then you would authenticate against the index server and tell the index server Okay, here's a new mogo. It's distributed on that in that URL And this information where the data is actually being distributed. That's also encrypted So the indexing server doesn't know anything about where the data is stored in the end You can spread data over several storage servers these servers do not have to be hosted by us You could store them you could store your data on your private infrastructure if you want you would just have to Open up a port on one of your servers and and let the the client software do the rest for you and accept packets from from from your identity We we have a strict separation between the structure of your data. So Who are you connected with? How are the mogos linked to each other and what kind of data is actually stored in them? and The service operate as I said independent of each other Let's just talk a little bit about a resilience to a tax in such a system If we assume the encryption state of the art and we can actually because we're not using a fixed encryption algorithm That that's all configurable and changeable over time Assuming that the encryption is state of the art then if Somebody has total control of one of these servers This person could obviously always harm you in a sense that this person could delete data on the server You could if you have physical access to the server you could just demolish it if you have Virtual access to the server you could still delete hard drives or anything, but the adversary will not be able to to Decrypt any of your data stored in there If an adversary has control of a total control of one of the servers this adversary will not will not be able to decrypt It will not harm your security or privacy. It will harm the safety of your data Accidental exposition of memory data, which is probably one of the most common security leakages If if that happens you would have to have first of all the the key stored on the end user device and then by accident a Basically The memory data of the other part of the encrypted key and you would have to know that these belong together If this is the case you could restore the private key and then you could probably If you also know the the password of the user you could authenticate against against the system If an end user device is being stolen you could just Disallow access and you could delete the second part of the private key and so the the part stored on the device would be rendered And if somebody controls the indexing and the authentication and the storage server not the authentication server That would be considered uncritical Yeah, but end user device and authentication server that would render the system Vulnerable that's a point where we are working on But it's clear one one part of the system needs to be controlled a little bit better than the others another concept before I Rep up the presentation another concept that we have is the concept of agents So assume what I talked about now is sharing data with persons But sometimes we want to share data with the system may be a company or may be a system that actually provides for example Full text indexing for your documents if you want to do a full text search And still a safe full text search you would require to have an index and this indexing process Might take too long to be executed on your end user device. That's why we introduce the concept of Agents which are technical users that can get access to your data if you share your data with them What you could do with that if you still want to keep your old Facebook accounts and you would still would like to post occasionally on Facebook But you have data stored in all mogul what you could do is you just set up a Facebook agent that uses the graph API to publish data in your name and you could Actually share One of your moguls with that agent this agent would publish it if you want and you would still see that There is information that you shared with Facebook So if you have all of your images in the system in in all mogul you could do a search With whom did I share any anything with this kind of? Social social network and you would get an answer to that question And I think with a graph API it should also be possible to even delete a post If you withdraw the access to the agent so that could be to be synchronized not all of the Social network or messaging system support that but at least posting should not be a problem and keeping Like the information in one place seeing with whom did you share that information that would still that would still be possible Okay, some some details on the implementation What we've written up to now is written in Scala, which is my favorite language Although coming from the embedded world. I like to code Functionally in my private time. We're using for all the communication infrastructure. We're using a car And for database access we're using slick the encryption is provided by the standard Java cryptography Architecture which gives rise to a number of pitfalls. I know that But we we created our own wrappers to allow Proper initialization and and and things like that The web protocols for the client. They're based on The jason web signature and web encryption protocols And the client software is available as a as a jar that you could that you could use to access The the backend service and the client lip are pretty much in an alpha version If anybody's interested I can share information Information on that the app is under development. I actually wanted to present you the app, but unfortunately our app developers wife just got her baby a few weeks too early and he didn't have time to finish it in Time for the conference here And we just started developing Agents for Facebook and and also incoming mails that could be stored in all logo as well So there's more to come by the end of October. Hopefully if if you like the ideas that that I presented Then just just just contact me. We're happy to to to we have others Joining us and Yeah, I'm open to your questions if there's any. Thanks a lot Yes, please So the question is is the system fully open source right now, it's not We're not sure if it will be My idea would be to share it at some point when we are more confident on on how how the things work Especially because we would like to have that system for the average user available and and and and spread But I still need to discuss that issue with my business partner the company as Founded last week actually is a profit company It aims at providing these services for companies as well So we what we would like to have is a system that's free of charge to use for everybody But we'd also like to distribute that system inside companies to do Like their internal data exchange because I think there's a lot of things Going on in the industry that are Actually wrong like sharing data over network drives copying it via email and so on that's that's what I discovered my daily life And that's something we'd like to Exploit if you may if you want to say so further questions. Yes, please That's okay, so the the point was that how can you trust us if it's not open source and I fully agree With that with that point actually So what we'd like to if if there's if there's an interest in the community I would like to give out parts of it by now And when the time is right, I would like to open it up because I I fully understand that that's available point. Yeah Thank you. Yes, please Okay, so the question is how would that my company make money and the the one answer I already gave was we were trying to to aim at the Business area selling it as an own infrastructure to businesses The other way of making money would only be possible. I think by selling storage space So if if you look at the if you look at mega for example Which is I guess also not open source They charge quite a significant amount of money for storing data on their service and Ultimately, that would probably be the case What I can imagine is that if you share it with companies and companies actually currently make money with your data that this This money is then given back to you because in this system you could be following The usage of data for different purposes if you give data that you hand out your data to a company why not Gaining something from it and may just be that the storage is is for free then Yes, please Okay, so the question is there a way of storing data on your Personal servers that are then accessible through the system, right? and the way to do that would be to install the the storage server component on your private infrastructure and Then create just a single certificate with which you can access that storage server and and add that certificate to your Profile to your encrypted profile on the authentication server Then the software would contact that storage server of yours to store data on it. Okay Then share Yes But in this case if you want to share an account you're sharing a public private key pair and what you're ultimately Losing is The knowledge of who actually stored something there It'll just be that single identity, but that's possible. We distribute the private key over different devices using different One-time pads you could also spread it to different users Using different one-time pads so that every user can have access of that key But again, that's like it saves you some time to to store all the encryption information Because you have to store fewer keys that have been encrypted But it compromises security a little bit. Okay. Thank you so much and thanks for your advice. Thank you