All right, so now we have the next talk in the Python Dev Room.
We're going to welcome Pascal Chambon, who's going to talk about PyFlexible
PyGraph 3 with Python and FlightBox. And it's going to be interesting to see
what FlightBox actually is. It says here that it's about
encryption-based access control. So very warm welcome to Pascal.
And this is going to be a longer talk, so he's going to have some things to show
there, so it's going to be nice. Thank you.
Thank you.
Hello, everyone. I'm happy. I'm excited to be here to talk with you
about these little things. So we are going to discuss powerful and flexible
cryptography with Python, of course, on something we call FlightBox.
You probably don't know because it's all you and not famous yet.
So I'm Pascal Chambon. I'm from France. And I am here not as just a freelancer,
but as part as a dev of the Witness Angel project.
I will talk a bit later about this project, which has led me to cryptography.
Whereas I was just another web developer before, and it was all new for me,
and I hope you will like it too. So what's the battle we are dealing with here
is that some data on many kinds of data need to be strongly protected,
really strongly. The problem is that control, access control to this data
can have lots of holes in it, lots and lots. So of course, there is a zero-day exploit.
You're unlucky. They found a bug in the Linux kernel. You can't do anything.
But lots of time is just that you forget to update your packages or there's a failure
in the update system. Only in a few months, your nice server is full of little holes,
vulnerabilities, even in the big and the major packages like Django and stuff like that.
There are also, of course, your bugs in your code, a problem with a previous escalation
and protected endpoints because there were deadlines and so something went wrong.
But it's not all. You can, if you do backups of your data, because you do backups,
of course, of your data, these backups can have a big source of trouble if they fall in the wrong hands.
So they must also be protected. These are also pirates, your credentials to learn
because they are on a post-it on the screen. It happens in lots of societies.
And of course, human malevolence and human errors everywhere, phishing, stuff like that.
So there are lots of attack vectors to your precious medical, personal data.
So we need something better than that. We don't want each update of our server to be a cause of potential drama.
For the anecdote, I have a cheap web host for my own little blobs.
Like two or three times in my life, I arrived to my website and the root of the web server was exposed,
the whole file system, so my data, and the data of thousands of other Django users because of a little mistake
in an NGNX configuration. Now we have containers, so it's a bit better, but still, at the moment,
I was a bit upset even though I have nothing important on my personal blobs.
So that's why I spoil the result. We need cryptography.
So let's go a little tour of the basics of cryptography.
Encryption, of course. So we use what we call a cipher, cryptographic algorithm,
to transform a plain text content. It's not always text. It's often not text.
It can be video, image, documents, whatever you want.
Encryption turns this into what we call a cipher text for the vocabulary,
and the cipher text is not text at all. Don't try to read it.
If it's readable, there's a problem somewhere. It's just zero and one in random order.
Not random, but incompressible. Then there's hashing.
Of course, most of you know, it's just taking a fingerprint, a little representation
of a potentially very big content. And then there's signing, which is a way to authenticate
to check the integrity of a content on most of the time to timestamp it
to know where, when it was created or updated. So that's the basics of the vocabulary.
Now let's talk about the first cipher type. It's the symmetric cipher.
So what is it? It's a box, but a box with a keyhole.
So you have a big key to go with it. So you use the key to close it.
You use the same key to open it. That's why we call it symmetric cipher.
This key is supposed to be 100% random in symmetric cryptography.
And the problem you have, if I give you this box, you can't open it.
I have to give you the key. So you have this awkward exchange of passwords
over SMS or email. You know, here is the password of the zip I gave you.
That's because of symmetric cryptography. Most of the time we use two channels.
We should, that's the minimum we can do, use two different channels
because if I send you the chest and the key, that's very interesting.
And we have another metaphor, which is a cryptex, a little chest
with the password written on it with little rings.
And when you put the right rings, you can open it and close it.
So that's the same thing. It's symmetric too, but it's not a key.
It's a password, so cryptex is closer to digital world.
No time for details. The slides are online.
You just have to remember these two things.
The winner currently this year is AES. It is everywhere.
So if you need symmetric cryptography and you don't have time to think a lot
on no precise needs, you take AES. Why?
Because it's very famous, very tested, very secure, and its performance is
especially great. Symmetric ciphers are very good at performance,
but they are hardware accelerated when you, when they, you can.
And AES has extensions to be accelerated on desktop platforms, servers,
and also little chips like ESP32, stuff like that.
They have extensions to do encryption very quickly.
So no problem to encrypt your whole hardware with AES or another symmetric
cipher. It just works. And it's quick and it's very hard to see the difference
with not encrypting, at least in my tests, or little chips.
Then there's the other one. If you have symmetric, of course,
you have asymmetric. What is asymmetric cipher?
It is another test so far. Same thing, but this marvelous invention
that I'm showing you, showing you the most expert-noddy things, it's a padlock.
It's marvelous. Why? Because I can give this open padlock to anybody.
And they will take this, I can distribute thousands of them.
They can put something, I don't know, here is some data, for example.
Most people will never, will not use any more what it is in a few years.
But we put it in the box, we close the box, we lock with the padlock,
and I have this key, I keep it, it is a private key.
It's not a secret key. Secret key is secret, but it's a secret you can share.
Private key is private, it's my privacy, it's intimate.
I must not give it to anybody. So I keep it.
And we have asymmetric encryption because anybody can lock,
anybody can trap data in a chest. Only I, the rightful owner of this key,
can open the chest. So the use case is a bit different
and very interesting, of course, in lots of cases,
because you don't have to transmit your private key.
You just transmit what we call public keys in the digital world
that are actually, we should have named them padlocks.
But it's a bit too late. We can do a petition, I don't know.
No time for details. Just remember when we talk about asymmetric cipher,
we talk about RSA most of the time,
even though it's not the best from a purely mathematical point of view,
it is here to stay. And the problem of asymmetric ciphers
is that they exploit mathematical operations that are heavy,
so the performance is bad. Do not encrypt your hardware with RSA.
Or unless you have very much time in your hands, it's not made for that.
So far, so good?
OK.
Then we have a little talk about digital signature.
So it's the good old stamp. I hope you all have a stamp because it's so classy.
And you have a fingerprint because it's a heavy operation,
like asymmetric, it's kind of like asymmetric ciphering.
So you apply this fingerprint on a content,
and you have a magnificent seal,
and you have a verifier, which is your eye in reality,
or a public key in the digital world.
And once you have stamped something, you have a proof of integrity,
of authenticity, and also of anteriority if you put a stamp.
But it's very hard to have a posteriority proof, almost impossible actually.
That's bad because we would have loved to have that for the Whitney Central project.
It's just impossible.
But anteriority is already very good.
You can show that this document existed before this day.
So an example are PIS, DSS, they are not very well known.
Most of the time, we don't care so much.
We use a trusted signer to do that.
So that's signature.
And here's my preferred primitive, what we call a primitive, a little operation.
It's a shared secret of Shamir.
So I don't know if Shamir was the only one involved,
but he managed to stick his name on this achievement
because I love this algorithm, lots of people love it.
It's something we don't do much in real life.
We have some data once more,
and we want to share it into what we call shards.
But we distribute these shards to N people,
and only N of them, a smaller number,
are enough to reconstitute the secret.
So it's not like when you cut a cake, it's more than that.
So here is an example of shared secret for a barrier.
I don't know for leading cause to pastures and stuff like that.
Each people has one key.
Each co-owner of the barrier has one key.
And each time you open a padlock, you can remove a little part of the lock.
And when enough of them have opened the lock,
you can pull the bar and you can open the barrier.
So I think most of the time here M equals 1.
So one person is enough to open the barrier,
but you can do fancy stuff like at least three people must come
until we can open, unless we can't open the barrier.
That's the secret of Shamir, and here is another example, and I love it.
You see you have some weird lock on the door barrier once more.
Any person that has one of these locks can open his or her lock
and then slide the bars in all the senses, and it opens the whole lock.
So it's unusual, but it exists,
and it avoids the problem we all have in our buildings.
You know everybody has the same key for the common parts like the trash room and stuff like that.
And when someone does dirty stuff or gives a key to somebody else,
we have trouble, we are forced to all change our key.
So the secret of Shamir helps with that in the digital world.
You can give parts of your secret to some people.
If some of them disappear, it's not a problem.
You get back your data.
And what happens in real life?
We use hybrid encryption scheme, as we call it.
So we use the performance of symmetric cipher.
It gives you a big key, a random big key.
We put it in the little box,
and then the person who has access to this data keeps the private key.
And then we stamp whatever we want, the data, the cipher data, cipher text, plain text.
There are lots of different cases.
Okay, so that's already much for primitives,
but we can already do much with these four primitives, these four concepts.
What did we learn when we studied cryptography?
Once more, we came from a web developer background where cryptography was not our problem.
It was dealt for us by frameworks, by web servers and stuff.
The first thing is that cryptography is dangerous.
It can be harmful.
Main lessons.
So that's maybe the most important part.
If you want to do cryptography, do not try to implement them yourself.
You will get hurt.
Other people too.
Just trust the big experts, the big libraries, pycrypto dom, the main 10 wide, of course.
Libsodium, OpenSSL and stuff.
They are not perfect, but they do much better than you will do yourself.
Second point to know, the order of operations is very important.
So even when the primitives are strong, if you mix them up, you can have useless results or bad results.
In this case, all I found was reading and reading and reading blog posts on the article on Stack Overflow posts
to understand if I had to sign before or after I encrypted.
Very important.
Do not use the same key for different purposes.
For example, my RSA key, if I use it to encrypt and to sign,
I have just given my key to my enemies.
So that's a very bad situation.
Same thing for what we call initialization vector, non-seize, that are values that are supposed to be used once and only once.
Most of the time, even if it's not mandatory, do it.
It's so cheap that why not?
Why not do it?
Of course, when we talk about randomness in cryptography, it must be really random.
So don't use a random source, if I can see that.
Use a cryptographically proven source.
On our desktop, it's not a problem.
Really, our operating systems do a good job finding randomness with the hard drive, on the CPU lag,
on the audio, the microphone, there are randomness everywhere,
what we call entropy everywhere.
But if you're on a little chip, on an embedded device, it becomes a real pain.
And there are devices for that, devices that just create entropy, randomness.
And sometimes that's the only thing you can do, because an embedded world is hard.
And also, sometimes you have to let it go, like for electric curve cryptography,
I was searching for the best curve, the word curve, to use for my cryptography,
and there were endless debates.
So in the end, just pick one which is about good, and don't try to be perfect,
because there's always someone who will discuss and say,
what was provided by the NSA, so we don't know what they did with it, things like that.
OK.
Now, some good news, because we don't want to get hurt, we did something for a reason.
Cryptography is strong, and when I mean strong, it's really strong.
It's not our usual strong.
For example, if you want to break that chest, symmetric cipher,
there's not enough energy in this room to break it.
OK. Not enough energy on Earth, not enough energy in the solar system, so far so good.
But there's not enough energy in the galaxy nor the entire known universe.
So, good for seeing this chest, even if you are put very, very interesting things in it, like cookies,
it's not worth it.
We don't have enough universes to break most of the chest.
So that's what we call strong in a cryptographic sense.
And that's good for us, because we have data which is sensitive.
If we want to break the little padlock, it's easier in some way.
You just have to be a mathematical genius.
You have to break discrete logarithm or factorization of integers or elliptic curve cycles, something like that.
If you manage that, not only do you break the entire payment system on the Internet, so you will have trouble,
but you also get a field of the middle, like the Nobel Prize for Mathematicians.
So try it, but we are kind of safe, and we will know it.
When someone will have broken this padlock, everybody will soon know it,
and we will have to change everything very quickly.
So it's not easy, still not easy.
OK, so far so good?
No question?
It's time to innovate, because everything I've just said is common knowledge in the cryptographic world.
It was only new for me and my fellows.
So what is the witness-essential project that I've been dealing with?
It's a black box for humans.
When a plane crashes, we want to know what happens.
When a human gets robbed, raped or worse, we want to know too what happens
to put the right people in the jail or not the wrong people in the jail, things like that.
So we want to get rid of judicial errors, we want to get rid of all these cases
where people cannot get justice because they have just no proof,
because in most of the time when people aggress you,
they try to not do that in a public place like today, like here.
But if we put spy cams everywhere, we have another problem, we have no more privacy.
Our Libertbertese can very quickly go downhill.
So our secondary goal, which is as important as the first one in Witness Angel,
is that we want to preserve privacy and get proof.
So it's a tough challenge. We need innovation.
So we invented Witness Angel recorders.
What's the concept is that you record stuff, okay,
but nobody can read what has been recorded and encrypted.
So it's a write only device.
You know the read only logs, read only files on your system.
That's the contrary. Anybody can write to this file, but nobody can read.
Almost, of course, nobody.
So it's a bit like, you know, the good old magician bags.
That's something, I love it.
You have some data, you put in it, okay, so far so good.
But you cannot have it.
That's the fun part.
So my data, what do I do?
So we have both security and privacy, okay?
We have what we call a revelation.
So I will have some of my key guardians, my trusted third parties, my mentors,
here to grant me authorization because I have been robbed, by example, on the way home.
So I need proof of who to bring to the judge that someone robbed me.
So I, of course, must grant authorization because I am the victim
and I am the owner of the data in here.
The key guardians, at least three of them, among five must grant authorization.
We need redundancy because some of them are in vacations.
Some of them have lost their key, their password.
It occurred a lot of times to me and my key guardians.
And we have a special case.
If I get murdered, I hope not, but we never know.
We have a special assembly of wise people and six of them, among the six of them,
four of them must say, okay, he has really been murdered.
So we have this special right to access his private data.
So when we do that, we recover the data.
Only in this case, only that data, not the other CDs that are here,
only the data of one hour before I was murdered, something like that.
And here I present to you, Meet Shidi, the little mascot,
little symbol of our project.
It's so cute because it's harmless.
It can help you.
It cannot betray you.
It cannot leak your new files, things like that.
So it's a big technical quest, of course, because we want a high-security level,
lots of different ciphers, because if someone breaks RSA, we want to be safe anyway.
We want multiple key guardians, what we call.
So some of them must be mandatory.
They must give their authorization like myself.
And some of them are optional.
A certain number of them must say okay, but not all of them.
So we are thinking about creating eBAC, which is encryption-based access control.
We know role-based access control or relationship-based access control.
There are lots of conferences on that.
But here we want permission to be based on something very strong.
So it's not very flexible in a sense.
In a sense that once it's in place, it's hard to change it.
But at least your data is very secure.
So we have begun the reflection.
Let's begin by chaining symmetric on the symmetric cipher.
So what we call chaining is just I have a chest with a cd-knit or USB key.
I put it in another chest.
And I close.
And I lock with my big key or my padlock.
And it's a logical hand, because you need both keys to access your data.
And it's like the Matryoshka doll, the nested dolls.
You can put as many chests as you want in the computer world at least.
And it's an easy way to chain our key guardians.
So that was the easy step.
And we were a big stuck.
How to do a logical or?
I have already spoiled the result.
We go back to that dear Shamir.
And we use the shared secret algorithm.
We showed a threshold, like m, and n, a count n of key guardians.
And we split our key into as many parts, and we give them a round.
And then we have different cases.
If m equals 1, if any key guardian is enough to open the chest,
then we have the logical or we wanted.
If m equals n, it means that all key guardians must give their shard
so that we can open the chest.
We have another kind of or.
So we don't even need the nested chest.
Shamir can do that too.
And if m is strictly between 1 and n, it's the shared secret.
So something unusual, but very, very important for us,
because it's securing the data and still having a workaround
in case of disappearance of one of the key guardians.
Let's wrap it up.
Let's put it all together.
So our data, where is it?
It's here.
It will go through several symmetric ciphers,
because data can be very big, can be petabytes of data.
We can put it in here.
Then we take the key on the part of key, the shard.
On each of them, we will recursively make them go through
symmetric ciphers, asymmetric ciphers, shared secrets,
etc., etc.
And at every step, when we want, we can timestamp stuff,
authenticate stuff.
That's a separate operation.
That's what it gives.
It can be a little scary at first.
We have a cipher tree.
So our key text here goes through AES on chat.20,
which are two symmetric algorithms, and becomes a cipher text.
That's the easy part of the pipeline.
It can be very quickly done with little chips.
They can pass the data, unencrypted, and put it on SD card on disk.
And here is the funny part of the algorithm.
It is, for example, the first AES key that was created.
I have protected it myself, me, with my RSA identity.
I didn't trust myself enough, so I asked for mom to,
for her identity to protect.
Also, we have two nested chests on my mom to protect the first
symmetric key.
So that's done.
We have one layer of security, which is already quite strong.
But that's not enough.
Chat.20, which is a byte stream and crypto, has given another key.
And this time, we want to rely on three-street third parties,
key guardian.
So we encrypt that key through AES in mode EAX.
And it gives a shared, we split the resulting blue key between
John and Jane.
Then we use AES in mode CBC, and it gives a key that we encrypt
with Jess.
And then the initial key, we make it protected by Jill.
So it's a bit complicated, but in the end, we have six key
guardians, me, my mom, and the four other people, that we are all
protecting in different ways the same secret.
Now, there's a little thing a bit weird.
Why?
Me and my mom, we just tacked our chest, one in the other, one in
the other.
Why didn't we just do that for John, Jane, Jess, and Jill?
Why did we complicate ourselves with other symmetric ciphers?
Here and here.
That's a bit weird.
There's a reason for that.
It's a bit just a trick, it's just for ergonomics when we
decrypt.
Because me and my mom, we have a problem.
We have nested our chest.
So when we want to decrypt, my mom, if she's in vacation, I
must wait for her to come back and open her chest, and then I
can access my chest and open my little padlock, which is it.
And so it creates a dependency link.
That's why we use symmetric ciphers here and there to create
new random keys, symmetric keys, the blue one, the red one,
and the initial green one.
And that way, each key guardian can have his or her shard to
protect.
It's just a way to remove dependencies between them.
They are all leaves in that big tree.
They are all on the external path, not stacked, and so it makes
an encryption easier.
But on a purely security point of view, it changes nothing
because E-A-E-S, A-E-S, sorry, is very strong anyway, doesn't
change much.
You can add it, you can remove it.
OK.
All that travel, all that road, let us do something that we wrap
in a little package and we call Fightbox, and we even have a
nice little logo.
That's about it.
Fightbox is how to protect one piece of data with multiple key
guardians with different access rights.
So, of course, we need something more concrete than just
these wild ideas, so we have a little workflow.
A key guardian is someone who will generate a key pair, actually
a set of key pairs, a digital identity, and like usual, like
in PCP, we'll publish the public part, the padlock to a registry,
and keep the private key to himself or herself.
Then we have a crypto conf, crypto configuration.
We have chosen the extended JSON format because it's so funny.
It's a way to store what anything you want about in a JSON.
It's used by PyMongo.
And this will describe, this tree will be described in JSON
format.
Then we have recorder devices, which will encrypt the content
using all these identities that are available on USB keys or
Web registries or stuff like that.
That's the first part of the workflow, and it gives us what we
call with much originality, cryptainers.
There are containers that contain both the encrypted data,
the ciphertext, and the metadata.
So it's self-describing.
The tree of key guardians is stored in there with the random
UIDs, with signatures, integrity tags, and stuff like that.
This cryptainer is like a little box, very, very safe.
You can store it anywhere you want.
You can store it by mail.
It's very secure.
You can even over encrypt it, put it in another, of course,
cryptainer if some day the security ciphers have evolved,
which will be, of course, the case.
And when you want to decrypt, then the key guardians,
they each receive their little box with their padlock on it.
They will open it if they want, of course, and return the content
via a secure channel, something a bit like PGP,
but we're using, of course, our already existing system.
This way we can retrieve all the little bits of keys and get
access to the data.
So far so good?
Okay.
Now let's go down to real business, because so far it can be just
vapaware and things like that, but we can already use this in
practice.
So how do we do that?
We have a reference implementation in Python,
WA CryptoLib, which we have worked on it for years now,
maybe three years.
We have changed our workflow.
We discovered the Shamir after one year, so we had changes to do.
And it has been recently audited, so I'm very, very happy,
because some young crypto analyst, Raccoon, has looked at the code
and said, okay, you are not screwing it up.
It works.
You could do better with this and this number of iterations of PKBF.
I don't know what.
So he gave us a list of little preconizations, but we have not broken
ourselves like you can easily do when you don't, you're not sure of what
you're doing.
And we were a bit scared at the beginning, but it told us it's okay.
It works.
The CryptoLib has grown up to be quite big in some aspects.
So we have utilities.
It's over by Cryptodome, the very well-known cryptography package in
Python.
You can, of course, generate unsalized keys in the PM format that you
already use on Apache and Genix and stuff like that.
We have some utilities to manage identities of key guardians, to group
them, to query them.
We have the support for USB devices because it can still be considered a
safe way to transfer stuff when you really don't want anything to be
online.
We have a little GZNRPC client with a custom exception translator that I'm
very proud of.
It allows us to communicate with our server and see the errors very, the
errors very easily.
And we have lots of sensor tooling.
So it's, it's more, it's more complicated than I thought.
When you have to push or pull data from camera, make microphone, GPS, it's
always different.
No, no, no sensor works the same.
So we had to make a pipeline to extract data aggregated for the
Polytar format and then push it to the encryption pipeline.
And, of course, we have the cryptanal encryption, which is the root of the
system, and ways to store and decrypt these cryptanals.
So here is the hard way using the Python API of WA CryptoLib.
What do we do?
We have some very sensitive data here, ABCD.
So first we are going to load our CryptoConf, which is in that file, on this.
And we have utilities that deal with encoding stuff like that.
Then we create a cryptanal storage.
It's a high-level structure to, to put lots of cryptanal together in a
directory.
And we give it what we call a crypt keystore pool, which is a set of
key guardians, actually.
And then we tell the system, go encrypt my data into a file called
rake with this configuration.
And if it succeeds, and it should succeed unless some key guardians are
missing, then you have your cryptanal.
So, of course, you must import your key guardians first.
We have lots of other levels of difficulty to manage more precisely
what you encrypt and maybe not store it on disk.
Maybe you want to stream it directly to a server.
On encryption, basically it was one shot.
So you had your mp4 file, your video file on your encrypted it.
But when we did some tests, of course, on Raspberry Pi, it was not
happy with gigabytes of file for some reason.
So to preserve the memory of it, we have been first to
introduce the proper way of doing it, which is streamed encryption.
So you have packets of data which arrive.
You encrypt them.
You dump them onto the disk.
And like that, the memory usage stays very slow.
But API is only for pitoniers and pitoniers that want to dig this
deep.
So we have a command line interface since last year.
And with a click, for those who know, a marvelous little library.
So here is how to do it with a command line interface, which you can
download for different, you have binaries for different operating systems.
First, you begin by importing your foreign key stores that are the digital
identities of your key guardians.
Here, I just showed, imagine, that I have plugged a USB key with the identity
on it.
And then we list the foreign key stores on UC.
We have two different ones.
We have AAA, which is, of course, a test key, and John Doe, which could be
a real key guardian.
They have seven on three public keys respectively.
And we have no private keys, and it's good.
Unless we are testing stuff, we don't want any private keys in our local
repositories, because in this case, they are not private anymore.
Now that we have key guardians imported, we generate a crypto conf.
So a crypto conf, you can, of course, write JSON by hand.
It works very well.
But if you have a simple use case, you can just use our generate simple
command.
You add key guardians one by one, you specify share secret, and it makes a
simple tree.
And here, we summarize this tree.
What did we do?
We added one EAS layer of symmetric encryption, one chat at 20 layer.
And inside the first layer, only the local device is holding the key, so it's
very insecure.
It means the keys are directly on the PC.
On the second layer, we have used two what we call automticators, which are
remote identities, really secure remote identities.
So this layer is really the one protecting our data, because as long as you
use local keys, you are not protected at all.
Yes, a little bit, but not much.
And then, it's time to encrypt.
So I encrypted my readme because why not?
With this crypto conf, I had just created.
And then when I list my cryptator, ta-da, readme.rst.crypt.
Maybe we will find a better extension later.
It has a size a bit bigger, of course, than just the plain text.
It is offloaded.
What does it mean offloaded?
Offloaded just means that the metadata and the ciphertext are split into files.
And it's a follow-readme, we don't care, really.
But when it's a gigabyte of video, you're happy to not put it into a json.
Because when you open a one gigabyte json, even your PC will not be happy.
That's why we offload most of the time.
The cryptator is created very quickly, and then the data is streamed directly to disk
by the encryption pipeline.
And then we have lots of other commands, of course.
We can purge cryptators, for example, in France.
We cannot keep more than one month the video protection data from the mailbox hole, for example.
So we purge them.
We can validate cryptators.
We can decrypt data.
And here, will it work if I call decrypt?
If all my keys are local, just for testing, it will work.
But in real life, no, I have no permission.
I don't have the private keys, so it will put some log and explain to me, a long log to explain to me,
I tried to decrypt with disk gigarian, he was not there, this one is there.
I need two, I have zero.
Your data is unavailable.
And that's what we want.
We're happy when we don't manage to decrypt.
On the third kind of use of Flightbox for now, it is a standalone program.
So we have it, we have binaries for desktop environment to play with it.
So it's with Kivi, a nice little framework, very cute and cross-platform.
So with this tool, you can record and you can also put it on Raspberry Pi.
It's compatible to have a little, for example, a camera station dash cam, things like that.
And we have little interfaces to import gigarian from the web or from USB to manage the cryptators,
to launch the recording on specify which IP camera to use,
and also a little workflow to aggregate permissions until you can decrypt.
So that you can play with it in the recorder software.
That's key guardians.
We have not talked a lot about key guardians.
There can be anybody in my building, we have five key guardians, Mr. and Mrs. anybody.
So that's why we have thought about them and we created mobile applications with Kivi again.
Well, I tell you it's great.
So this is Python working on Android and it also works on iOS.
So it's unusual.
We had a very hard time doing it, but it was fun and it works for now.
So no policy change occurs on Android or iOS.
So you have your little program which allows you to create your digital identity, publish it, check it,
check that your password, your password phrase, as we say, is still working.
And most importantly, you can manage the permission, the request that you get and say,
I authorize you or not.
So I have been installing parcels in my mailbox and two times the neighbors have given me permission to see that it was a deliverer
that stole my precious parcels and so the filters for Roomba, you know, they stole,
but at least I knew what happened.
Thanks to this authenticator.
So here is the dash cam, for example, Raspberry Pi Zero with a little screen.
It works.
It's just not very simple.
It's a bit clunky.
And for example, I can film anything I want with this one because I lost the key years ago.
So I can dance naked in front of it.
I have no risk at all.
Nobody will ever be able to decrypt that unless some aliens invade Earth.
But that's another trouble.
So we have some prototypes to put in a handbag, some prototypes to put in, to replace dash cams of cars,
and also to replace video surveillance, video surveillance in, yes, everywhere actually.
All the cameras we have in the streets that are deeply insecure to me can be replaced by witness angels
on this way when there is someone burning your car.
You ask the neighbors, but they're key guardians, can I see who burned my car?
And they say yes or no.
If they say no, maybe you have a problem with your neighbors.
But you see the principle, privacy first.
And you can't do it secretly.
You have to ask publicly, hey, girls, I have a problem.
So we have a flight box in Python, and we could make it work in micro-Python,
but micro-Python is still huge for tiny chips.
So we are currently re-implementing the best part of it, the encryptor in C.
That way we can put it about everywhere actually.
And we have a huge challenge because we want to do a portable shivy, a little familiar, a little pet.
You have in your pocket, you have on your J-wall, especially if you're a girl,
you go anywhere with it, and if you have some trouble, because you can have some trouble even in France,
then you can go to the judge and show your J-wall, and there will be an angel in it telling the judge what happened
with proof, with lots of proof, timestamp and stuff like that.
It's a big challenge, so it's a little moment where I ask some of you if you have some contacts
or some free time in hardware development in open source, cheap creation,
we are starting this project and we know it won't be easy, but it's necessary.
We have to last one day on a tiny battery, some Chinese product do it, or they pretend they do it.
We know it's possible, but it's a huge challenge because we have to optimize everything from the sensor to the SD card.
So we use Flightbox for justice, but there are lots of other cases.
You can use it for protecting your credentials.
That's a hashicorp, does it with the vault.
They have a vault when you have to output several passwords from several persons of the enterprise to access the server credentials.
Same thing for your couple or family photos.
You can decide that me and my wife, we both have to input our passwords from very sensitive documents
that I could give if I had a gun on the head, but she would not be there.
She would not have the gun on the head too, possibly.
You see, double security.
And also we can replace file transfer systems with Flightbox, a little Flightbox,
no need for thousands of Kigadian.
And there are lots of businesses probably to do about it.
We just don't know them.
So if you have ID, go take it, it's open source, and make money with it.
That's the part.
Thank you for listening to me.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you very much for the really interesting talk.
So now we all know what Flightbox is.
Are there any questions?
Do you have any hardness proofs?
Currently, you said you had a recent audit, but proper proof of your library.
You mean certification?
Not exactly, but cryptographic hardness proof, like some publication that people can analyze.
Yes, the code is all online.
But we have not had a big name certificate, just a hacker from internet.
But yes, we try to certify as soon as we can.
But no, we don't have a big enterprise saying, okay, it's safe.
Okay.
Yet.
There was one more question.
I'm interested if this is used only for files that are already saved, backups,
or you can use it in the, for example, a relationship database for the data inside.
While it's created and read it.
So the question is, can it be used in a database that's it?
Yes, but in real, in live database.
The Flightbox, the core concept is that that data can be written very easily, but it's hard to read.
It's even very long.
So in most cases, it will not work for a live database that you use.
But I am currently brain storming myself because I would love to have a special database system,
like SQLite, that you encrypt with Flightbox.
And when you have enough authorization, it goes live.
It comes in memory, like in memory SQLite.
And you can access this until it shut down.
But it means you will be granted access temporarily to a live instance of your database
when your neighbors, your boss, have said, okay, you have one hour to do stuff with the database and then it's gone.
But it's a very specific use case.
Yes, we cannot use it on your live HDD or live database.
Thank you for your presentation.
It was awesome.
Nice examples from real life like logs, chess, pads.
It was very awesome.
My question is half psychological, half technical.
Because we live in a very dynamic life, I mean the relationships.
And I would like to ask how it looks like the process of management of the accesses.
How to add new angel, how to remove angel.
So yes, about the management of these permissions, actually.
That's the hardest part.
That's the hard part with flight box because it is meant to be once that is encrypted.
My neighbor was unhappy because he wanted to reset his passphrase.
I had to explain to him that there's no reset because nobody can recover the data when he has forgotten the password.
So we can easily add over encrypt and add key guardians.
If we want to remove or switch, we have to decrypt everything or at least this layer, you know, up to the layer on re-encrypt.
And there are homomorphic encryptions.
There are things that look very promising to modify, but I really don't know them well.
I know there are some researches and things like that.
But for now, maybe for a long time, the only option will be to decrypt and re-encrypt.
More questions?
Hello, thank you for your talk.
Looking at your hardware devices like safety camera and protected with angel,
my question is if you do something to protect the channel from the camera before it gets encrypted
because a nasty actor that have physical access to the camera can niche on the bus.
Yes, so there are lots of aspects we are thinking about concerning the hacking of the device.
So there are lots of ways to hack into the device, but it's much easier to buy a spy cam on the internet and wear it.
So the spy cams are already there.
You can already use them on an event you could fake that it's a witness angel.
That's a problem we are thinking about.
That's why we want full integration.
That's why we want a witness angel chip that contains the camera sensor.
And even that signs with a trusted platform model that signs the frames as they go by.
Because now that we have the era of fake news, anybody can indeed create a video of you saying or doing whatever he wants.
And we would like witness angel to be a countermeasure to that by having devices that have their own signatures
and that show that they are well taken by a witness angel.
Of course, there are always a simple solution to film a screen showing a video of fake data.
So it's a problem that for now nobody has resolved, but we can go as far as we can.
And the farthest we will go is having our own device with all integrated.
And if you try to open it, it explodes.
That will be the goal.