Please welcome Nils. We've managed to solve a laptop problem.
Nice to be here. I'm going to talk about the 6th project and I'm going to apply it to software updates.
Let's start in point is digital signatures. I imagine some of you really software and you
probably sign your releases. Others install software and hopefully verify the signatures which is a little
hard to do manually. The good thing is that lots of tools if you do up to get update upgrade,
if you do Firefox automatic update and that's very fast signatures for you and enforces
value signatures which is all very good. But wouldn't know if one of the involved private keys is compromised.
That's kind of hard and that's the issue that will be the focus of this task.
So I will spend quite a bit of the talk to explain the 6th system.
Then I will get back to the software update use case in some detail and then do a summary.
And I'm Nils. I have been working at Glass Club with the 6th and 4th or 2 and a half years.
I'm also the maintainer of the new network library and some other stuff.
So what is a transparency log? It's an append only log of entries.
Internally it uses a neural treat to make things efficient and it's intended to work like a public bulletin board with a special property.
That once you post something on the board it stays there forever or at least until you destroy the entire board.
You can't modify notice or remove it once it is posted.
6th is one project in this space. It's a rather minimalistic transparency log.
It's a free and open software project started roughly five years ago.
Last year we have spent some effort on making sure that specs are stable and the tools are in a reasonable shape you can start using it.
So the setting here we have automatic software updates.
There are properly signed, but a tackle gets controlled of the really signing key.
For example, you to key compromise or coercion of the legitimate keyholder.
And then that tackle uses the signing key to sign malicious updates and deliver those to some small number of target users only a targeted attack.
And what can we use transparency for? We will not be able to prevent this kind of attack, but the point is to enable the detection.
And if we can detect it, we can try to recover and that's kind of out of scope.
We talk what you actually do when you discover that there is a rogue update distributed summary users.
So the detection is the point here.
The threat model we consider are the powerful attacker.
The attacker owns your really signing key, attacker owns all your distribution infrastructure.
The attacker also owns our Sigsam log server and some but not all of the co-sign witnesses.
And in this setting, we aim to detect attacks.
And by enabling detection, we also have to deter attackers because some attackers might.
They would be happy to do an attack if we can do undetected.
So now we go into some details of the Sigsam system.
The log entries are logged, check the assigned checksums.
So this is the log entry.
It's a checksum that says, what was logged?
It's a public key hash that says, who logged this entry?
And there's a signature that proves that the whole corresponding privacy actually was involved in creating the log entry.
Sigsam is a sign for public use that we want to enable public log servers that any application and use can send stuff to.
Even if the log operator doesn't know or trust these users.
And it's minimalistic with the aim that they can use sort of building block for various other transparency applications where the software update thing is the main focus of this talk.
These are the different things in the in the system.
To the right, we have the familiar setting, we want this data to users.
We want to sign it and the user can verify that it's authentic.
We add the log server, we add the monitor that can detect when bad things happens.
And we have the witnesses that provide security in the system.
And I will describe this in some detail.
For the user, if you don't have Sigsam, you have a public key, you get signed data, you verify the signature you're fine.
If you have Sigsam, you extend the signature with the proof of logging and extend the public key with trust policy.
And you verify the data, but it's still offline verification.
It's the different kind of detached signature.
When you sign stuff without Sigsam, you just have a private key, you sign stuff, you distribute it.
With Sigsam, you also send the sign Sigsam to the log server and you get back a proof of logging.
And then you distribute a proof of logging together with the data to your users.
And one potential problem here is that the logs are ought to be available at signing time otherwise this will fail.
So the log has to be available as another component.
Monitoring without Sigsam, you don't have any monitoring.
When you introduce Sigsam, the monitor repeatedly tells the log, looks at all entries, looks at signatures from entries of interest from public key of interest.
And the objective here is that any signature that will be accepted by a user will also be seen by the monitor.
You can also extend the monitoring to also take the actual data into account to verify.
For example, if the release is supposed to be reproduced with the monitor, you can get the corresponding data and try to verify that and scream if it doesn't verify.
To make sure that users and monitors what's in the log, it's critical that it's the same log.
So what if the log looks different depending on host asking.
And we don't want to just blindly trust the log to do the right thing.
We don't want a single point of trust.
And that's why we have witnesses.
Typically, the log sends its current state to its witnesses and hopes to get the co-sing that are back.
And when the witness co-signs the log state, it says, all the older entries that the co-sign proves that they are still in the log.
It's really at only append, only like it should.
And for the log to convince the witness do that, the log has to send it a consistency proof of the ties to the old and the new state together.
The witness co-signatures are included in the proofs of logging.
User can require co-signatures from M out of N trusted witnesses.
And if users or monitors are configured so that they agree on the trusted witnesses, then this ensures that users and monitors see the same view of the log.
Witnesses are light because they only, they don't care about the content for the log.
They only about consistency.
The smartest requirements on storage processing and bandwidth.
And a single witness can serve many transparency logs, not even, not only seeing some logs as a kind of transparency logs as well.
And doesn't need any publicly known IP addressed thanks to this optional bashing thing that lets the witness be a bit more in hiding.
And the log will only access the witness via the bashing.
A witness has a does need secure and reliable operation.
So if you have the ability to run stuff securely for a public good hosting witnesses, it's a very good thing to do.
Similarly, the trust policy can look like this.
It specifies one or more logs.
Any log in the list is acceptable.
It defines list of witnesses.
Logs and witnesses are identified by the public key.
The URL is used when you submit stuff to the log, but it's ignored when verify proves.
And then you can define groups with thresholds.
This example sets a core where we have five companies that might be trustworthy.
And we require at least a valid code signature from at least three of these witnesses to accept a proof of logging.
So a bit of demo how to use this for software updates.
We would first, if you want to apply this, you first have a setup phase where you decide logs on witnesses to rely on.
That is the trust policy.
You distribute this to your users.
You also have to register a rate limit key in DNS because that's how we rate limit public submission to the log.
Then in the pipeline that creates your releases, you add the step that is submit the signature to a six-on-log and in your update agent.
You would need to verify these proofs instead of just verifying a plain detached signature.
And then you add a monitor that can respond to unexpected entries in the log.
And verifying these claims like reclubild claims.
So you have to set up phase without tooling.
We have the policy access thing.
Our test log because that way we can run the demo without actually putting stuff in DNS.
We install latest version of our Sigism Go tools.
We generate a submit key which would be then the long-lived release sign in key.
The rate limit key which is of less value and can be rotated easily.
And we create the record we would have to put into DNS to be able to use this when passed by the rate limit system.
In the release pipeline, you create the release artifact here release.gzip.
You submit it to the log. You have to give this six-on-submit the policy.
The private key used to sign and your domain and your rate limiting private key for to make valid request.
And then you have the artifact release.gzip that you want to submit to the log.
And then if all goes well, you get back.pro file and you distribute those two files to your users.
For the agent, let's first have a close look at the proof.
It then was the log. It was sent to.
It gives the signature and key hash in the log.
Then we have the state of the log with size and root hash.
The signatures from the log itself and from the witnesses.
And finally, we have the inclusion proof for the entry in the log with the index and the list of hatches.
And then to verify this.
The document line tool is six-on-verify. It takes the policy.
The public key that should have submitted this to the log.
The proof and the artifact itself.
And that's it.
We have a monitor which is a bit of work in progress, but you can run it like this.
Give it a policy and the key you are interested in.
It will tell all the logs mentioned in the policy and write out a line when it finds an entry that is signed by the key you specified.
So here we find one entry with index and key hash checksum.
The signature has already been verified by this tool.
And this corresponds to what we submitted to the log in the previous slide.
The flip with one of our early users.
Yes, it's up this for release of his Aga and Clip from tool.
And customers have done proof of concept monitor.
The compares what's in the log with what's on the GitHub release page, which is very nice.
So to sum up what is six-on.
It's a public record of signatures.
And that's useful because signatures have meaning to applications.
For example, the signature by your release key means that the signed artifacts are official releases.
And it's trusted when witnessed by sufficient number of witnesses.
concretely, use submit and collect the proof when you sign stuff.
You have to bring your own distribution network to get data and proof to users.
Users do offline verification, just like any other detached signature.
And then you monitor the logs for keys of interest.
You can do it yourself and third part is can do that as well.
So get going and do transparency with six-on.
We have one log up and running.
We have one witness running at Mulvod since yesterday, I think.
We will very soon now have our own witness up and running online.
We have documented our operational procedures to get that done in the secure way.
Google has the armed witness project that does witness thing in a compatible way.
And witnesses are a log.
So I think it's time to get started to use this system.
And finally, I want to mention some other use cases.
If you can do transparency of a stage access, we can do break loss emergency access.
If you want to be able to in several circumstances have access to user data.
But you want that to be detectable when that mechanism is used.
We can have vulnerable.
The submissions where you submit a vulnerability report to a service that promises to publish this in 30 days.
If you get a receipt that it is put in a public log, you can monitor that it actually is published in a timely fashion.
So that's all on www.sixam.org.
You can find contact info, docs, source code, everything.
Thanks.
Questions?
Yes?
How does the witness know if the release was legitimate or if the cyber has been further?
The witness doesn't know that.
The witness facility will look at the log entry.
The witness says that I will co-sign this log some time ago.
And I am co-signing it again.
And I have verified that everything that was in the log is still in the log and has not been modified.
That's the only claim that the witness makes.
This is a contrast in monitors.
Monitor read the entire log.
All entries verify inclusion proves and extract the entries for keys of interest.
And then the monitor wants to know if this legitimate entry.
And that depends if you are the key owner.
You would supposedly know what you should have signed.
And if you find unexpected entries that could be key compromise or something that happened.
If there are additional claims like a reprobile claim,
then also third party monitor can look at these entries and verify those claims.
So if it's my key and it's somehow stolen.
Yeah.
As on the side of it, I can say, hey, this is a song that should be in there.
But if somebody takes a robber hold in both groups,
I will not use case as part of it.
The thing is, we should cover both cases.
There are some scenarios that the user will verify these proofs.
So if a packet does it, it makes a signature but does it log it.
The signature will not be accepted by the targeted user.
And if the packet attachs into the log, the user will accept it and bad things will happen,
but you will be able to detect it after the fact because it's in the log.
I think I bet we understand.
It's a bit counterintuitive that it's no prevention, just detection.
Another questions?
For the user's point of view, the idea is that you get the data and the proof in the same way that you get the data and the detects signature today.
So we don't do any distribution or service.
Yes.
So if I understand this correctly, this relies the defense against being encouraged to send something
to the user.
If it's not submit to the log, the signature will not be accepted.
And if it is added to the log, it will be detected after the fact.
You need to tell the user that they actually need to verify this against the inclusion proof.
Anybody who is forcing you to sign something would also know that they would have to force you to submit it to the log.
And also.
Okay, let's see if I got the question.
I didn't quite grasp the question.
So I need to tell users that they need to use this to verify the signature and the inclusion proof.
So if somebody is forcing me to do a signature, that somebody knows that they also need to force me to submit into the log.
So now does it protect against being encouraged?
So it's an assumption that the user's enabled strict verification.
We don't get the value before that happens.
So the user is using the user's configured to require this proof of logging.
And then the attacker encourages you to make a signature.
And then for that signature to be accepted to the user, the attacker must in some way,
or the other get the signature into the log.
And when it's in the log, it will be eventually be visible.
Yeah.
Are you talking to an FPGP or X49 or SSH to add this to some other existing sign-in tools?
So far, the question is if we are talking to PDP,
or the other tools to add this kind of extended signature?
No. We haven't got some starting with that yet.
And I think we will have to do it some one application by.
Yes?
Does the witness act like some sort of an inclusion proof, for example,
like a city in the sort of cryptocurrency ecosystem?
Or is it budgeted?
The question is if the witness does something related to the city in the CTA ecosystem?
I think.
Does the witness act of the process?
Are you putting witness in this process?
Equate to inclusion with this?
It does.
Does the witness is doing inclusion proofs?
No. I don't think.
If I got the question about that, I think that answer is no.
To inclusion proofs are in the logging proofs sent to users.
And witnesses use consistent proofs to verify that the log behaves in an append-only way.
Question in the back?
Can you register as a witness?
The question was, can anybody be witness?
And can you register a lot of witnesses to overheld the policy?
And the answer is that getting a witness to which log requires some kind of ping-pong or configuration between the log and the witnesses.
Both parties must agree that they should talk to each other.
You can't unilaterally witness a log.
And the second part is that you do this majority check on Thursday check.
Only against the witnesses that are listed in your trust policy.
That can be another thousand coaching editors.
But those are by keys that are not known to you.
They are just discarded before it makes this policy decision.
We can take one final.
Yeah, the user verifying the proof decides that.
And it's rather important that it's done in coordination with the monitors that the user will also be relying on.
One final question.
Yes?
Is there a single sign and multiple witnesses?
Yes.
The question was, what benefit do we have over having multiple signers?
I think having the trust in multiple witnesses is somewhat similar.
What we'll get here is that we can see all the signatures that were made.
You can do this and have multiple signers.
And then for each of those signers, you can see if they make an unexpected signatures.
Thank you, Nils.