WEBVTT

00:00.000 --> 00:17.000
Okay, I want to start my talk.

00:17.000 --> 00:24.760
The title is remote attation on arm torsion of t with the rise on the required.

00:24.760 --> 00:30.760
So this one is corroborate with U.H. Tsugiyama at the critical security.

00:30.760 --> 00:35.760
So this slide shows today's contents.

00:35.760 --> 00:39.760
At first, I want to introduce opti and the horizon.

00:39.760 --> 00:48.760
After that, I want to talk about my end development, remote attation on opti.

00:48.760 --> 00:52.760
With the rise on the horizon barrier.

00:52.760 --> 00:59.760
It requires predictive visit and provision in the face and remote attation face.

00:59.760 --> 01:05.760
I'll post the current status and I'll talk about three future plans.

01:05.760 --> 01:14.760
Key management using HSTM and the cable confirmation and set key based attestem keys.

01:14.760 --> 01:18.760
And I want to conclude this talk.

01:18.760 --> 01:24.760
And the context is very popular on smart home.

01:24.760 --> 01:27.760
Not only smart home, the game must be used.

01:27.760 --> 01:30.760
For example, Nintendo Switch.

01:30.760 --> 01:38.760
So the opti is an open source.

01:38.760 --> 01:42.760
Secure OS for context.

01:43.760 --> 01:49.760
It's for us the global home's API.

01:49.760 --> 01:57.760
So global hot GPT grant API and GPT internal.

01:57.760 --> 02:04.760
The opti has a simple attestation mechanism.

02:04.760 --> 02:08.760
But it does not satisfy the current limitation.

02:08.760 --> 02:15.760
So we developed a total remote attestation mechanism who opti.

02:15.760 --> 02:19.760
So the horizon is a very fire.

02:19.760 --> 02:22.760
The open source is very fire based on IT graph.

02:22.760 --> 02:27.760
This figure shows the load and adpact.

02:27.760 --> 02:30.760
Load means the person do something.

02:30.760 --> 02:35.760
And adpact is an information.

02:36.760 --> 02:39.760
This figure has two phrases.

02:39.760 --> 02:46.760
So the green part is rolls at provision phase.

02:46.760 --> 02:52.760
And pink part is adpact at provision phase.

02:52.760 --> 02:58.760
So the rolls and many information to verify here.

02:58.760 --> 03:04.760
Not only verify here, the information is used by attestem.

03:04.760 --> 03:05.760
Attestor.

03:05.760 --> 03:08.760
I talked a later detail.

03:08.760 --> 03:16.760
At remote attestation phase, verify here is this adpact.

03:16.760 --> 03:22.760
And attestor send a remote attestion evidence.

03:22.760 --> 03:29.760
The evidence is verified by attestor and make a attestion result.

03:29.760 --> 03:44.760
So the green part decides attestor is not.

03:44.760 --> 03:50.760
So let's also require C-bar-home attestation evidence.

03:50.760 --> 03:55.760
We implement this part.

03:55.760 --> 04:01.760
This figure shows the software we developed.

04:01.760 --> 04:04.760
The most part is opti.

04:04.760 --> 04:10.760
We developed opti API to create the attestation address opti.

04:10.760 --> 04:13.760
This part.

04:13.760 --> 04:20.760
The API calls P-T-A, so the T-A.

04:20.760 --> 04:24.760
So the T-A works as a part of opti.

04:24.760 --> 04:30.760
The P-T-A measures a shared 2-5-6 of opti.

04:30.760 --> 04:32.760
This part hash.

04:32.760 --> 04:36.760
And the creator attestation evidence is C-bar-home att.

04:36.760 --> 04:40.760
After that, P-T signs attestation evidence.

04:40.760 --> 04:53.760
We also developed sample software to test this.

04:53.760 --> 05:01.760
The part sample T-A, sample C-A, cranked up, sample line party,

05:01.760 --> 05:05.760
and sample setting of the horizon.

05:05.760 --> 05:10.760
We developed.

05:10.760 --> 05:15.760
So this figure shows the provision in a phase.

05:15.760 --> 05:22.760
Before provisioning, we need sample prequisite.

05:22.760 --> 05:28.760
So, and also, in this case, opti of the builder.

05:28.760 --> 05:36.760
Opti builder have two prepear signing private key and signing public key.

05:36.760 --> 05:42.760
And also, prepare signing key ID and sign ID.

05:42.760 --> 05:52.760
And the reference bar is offered by T-A builder.

05:52.760 --> 05:57.760
T-A builder offer a T-A ID.

05:57.760 --> 06:03.760
After the T-A, they measure hash.

06:03.760 --> 06:08.760
This information is used by provisioning.

06:08.760 --> 06:14.760
So, rule part is attestation and error part is verified.

06:14.760 --> 06:25.760
So, at first, endorsement offers signing private key and signing key ID.

06:25.760 --> 06:30.760
And sign ID to P-T-A of opti.

06:30.760 --> 06:35.760
It works as a signer.

06:35.760 --> 06:45.760
So, T-A get ID from T-A builder.

06:45.760 --> 06:53.760
The hash bar is baried at runtime.

06:53.760 --> 07:01.760
So, T-A does not know the hash bar is.

07:01.760 --> 07:26.760
So, signing public key and signing key ID and sign ID is used by Verizon.

07:26.760 --> 07:36.760
And, as a reference bar, T-A ID and hash bar is set to Verizon.

07:36.760 --> 07:47.760
So, this part, yeah, I talked about later.

07:47.760 --> 07:51.760
So, this slide another day of provisioning.

07:51.760 --> 08:01.760
So, T-A builder, T-A builder, T-A ID and make a T-A.

08:01.760 --> 08:07.760
After that, T-A builder measure hash bar is opti developer,

08:07.760 --> 08:15.760
P-A signing key and signing public key and signing key ID and sign ID.

08:15.760 --> 08:25.760
Signing key is used by P-T-A and signing public key is used by P-A provisioner.

08:25.760 --> 08:35.760
So, in this case, provisioner sets the verifier.

08:35.760 --> 08:45.760
So, this slide is result of Verizon provisioning.

08:45.760 --> 08:55.760
So, this slide shows the error part is signing public key and property ID.

08:55.760 --> 09:07.760
So, this slide shows the remote extra place.

09:07.760 --> 09:15.760
At first, she or gang party send her already quest.

09:15.760 --> 09:23.760
After that, verifier send back already quest with nouns.

09:23.760 --> 09:35.760
So, grant up send already quest to T-A.

09:35.760 --> 09:39.760
T-A knows T-A ID.

09:39.760 --> 09:46.760
So, nouns on T-A is used by RAPI.

09:46.760 --> 09:56.760
RAPI is processed at attached P-T-A and makes RAPI.

09:56.760 --> 10:01.760
If then send back to verifier.

10:01.760 --> 10:06.760
So, RAPI result is send to the gang party.

10:06.760 --> 10:10.760
If RAPI result is good.

10:10.760 --> 10:20.760
Lange party and T-A makes a communication.

10:20.760 --> 10:22.760
So, current status.

10:22.760 --> 10:28.760
The code of OPT was merged by OPT-O-D line.

10:28.760 --> 10:34.760
The sample code are confirmed on QM and Raspberry Pi.

10:34.760 --> 10:44.760
We are now trying to update examples.

10:44.760 --> 10:48.760
So, from here, I want to talk about the future plan.

10:48.760 --> 10:56.760
So, current implementation and bets are signing key in the P-P-T-A binary.

10:56.760 --> 10:58.760
So, it's not so secure.

10:58.760 --> 11:08.760
So, I want to use key in H-S-N.

11:08.760 --> 11:12.760
So, there are two solutions.

11:12.760 --> 11:16.760
We have another plan, white box cryptography.

11:16.760 --> 11:22.760
But white box cryptography are not so secure.

11:22.760 --> 11:24.760
The same are we think.

11:24.760 --> 11:30.760
And we are now planning to use secure element.

11:30.760 --> 11:34.760
C-A-M of N-X-P-A-C-P-U.

11:34.760 --> 11:40.760
It depends on our target board.

11:40.760 --> 11:44.760
So, next future plan use secure boot confirmation.

11:44.760 --> 11:50.760
Because current remote attesium does not measure.

11:50.760 --> 11:52.760
It confirms the secure boot.

11:52.760 --> 12:02.760
However, the boot process is mutable.

12:02.760 --> 12:08.760
Because the B-L-1 is mutable.

12:08.760 --> 12:18.760
So, we can change the B-L-3 parts.

12:18.760 --> 12:34.760
So, we want to confirm the secure boot of secure OS.

12:34.760 --> 12:36.760
In this case, OP-T.

12:36.760 --> 12:40.760
So, the third plan is a certificate based attestation key.

12:40.760 --> 12:46.760
So, current implementation use signing key directory.

12:46.760 --> 12:50.760
It's not scalable.

12:50.760 --> 12:58.760
We want to use PK-SAT-SAT-SAT-SAT-SAT-SAT-SAT-SAT-SAT.

12:58.760 --> 13:06.760
In order to use PK-SAT-SAT-SAT-SAT, the device build-up become endosvent.

13:06.760 --> 13:12.760
Each device has its own key PK-SAT-SAT-SAT-SAT-SAT-SAT.

13:12.760 --> 13:20.760
So the verifyer also has to issue us load sativate.

13:20.760 --> 13:29.760
So it makes scalable, however, the endosar must take a pk sativate whole sign in key,

13:29.760 --> 13:32.760
and the verification.

13:32.760 --> 13:37.760
The verification process is a little bit complicated.

13:37.760 --> 13:46.760
So in this case, there are two endosarment device builder and opti builder.

13:46.760 --> 13:52.760
The device build-up prepared sign in key,

13:52.760 --> 14:03.760
and the sign in private key, have to get pk sativate from load CA.

14:03.760 --> 14:14.760
So as the provisioning, the sign in key and pk sign in key ID,

14:14.760 --> 14:23.760
and pk sativate is set by HSM device.

14:23.760 --> 14:30.760
So the sign in key is also assigned at pta.

14:30.760 --> 14:37.760
Also has a TID and Verizon.

14:37.760 --> 14:45.760
Verifier has to get a load sativate and other IDs and hash.

14:45.760 --> 14:54.760
So this is this finier compared to implementation.

14:54.760 --> 15:00.760
And honestly, this finier does not show scalability improvement,

15:00.760 --> 15:09.760
but the future is more scalable.

15:09.760 --> 15:13.760
So it can keep the scalability.

15:13.760 --> 15:22.760
And another flaw is verifier sign ID.

15:22.760 --> 15:27.760
So currently implementers use sign ID.

15:27.760 --> 15:36.760
However, there is no guarantee for signer.

15:36.760 --> 15:41.760
So if the code of signer should be verified.

15:41.760 --> 15:52.760
So the second future plan has take a second confirmation with this answer.

15:52.760 --> 15:55.760
Okay, I want to conclude my talk.

15:55.760 --> 16:02.760
I report the current opti's Verizon verifier.

16:02.760 --> 16:06.760
So there are three future plans.

16:06.760 --> 16:12.760
Thank you, thank you for listening.

16:18.760 --> 16:22.760
How long sign in key ribs?

16:22.760 --> 16:28.760
Oh, in this case, sign in key ribs.

16:28.760 --> 16:39.760
You are in we use pta.

16:39.760 --> 16:42.760
So it cannot change.

16:42.760 --> 16:48.760
So if you want to change, you have to leave the pta.

16:52.760 --> 17:15.760
Sign ID sign ID sign ID sign ID sign ID sign ID.

17:15.760 --> 17:21.760
Yeah, yeah, yeah.

17:21.760 --> 17:25.760
Current implementation is a sign ID.

17:25.760 --> 17:29.760
Yes, no guarantee now.

17:29.760 --> 17:31.760
So I want to improve.

17:45.760 --> 17:55.760
Okay.

17:55.760 --> 18:01.760
Yeah, yeah, yeah, yeah, yeah.

18:01.760 --> 18:13.760
Yeah, yeah, yeah, yeah.

18:13.760 --> 18:17.760
I guess this part.

18:17.760 --> 18:21.760
Okay.

18:21.760 --> 18:27.760
So we also verify the B2 and B3.

18:27.760 --> 18:31.760
Yeah, not only B2, not only it only.

18:31.760 --> 18:32.760
Okay, only.

18:32.760 --> 18:35.760
Okay.

18:35.760 --> 18:36.760
Okay.

18:43.760 --> 18:55.760
Okay.

18:55.760 --> 19:03.760
In this case, we want to use grant side.

19:03.760 --> 19:05.760
The question is,

19:06.760 --> 19:12.760
Hsn is used grant side or sub aside.

19:12.760 --> 19:20.760
The answer is, in this case, grant side.

19:20.760 --> 19:30.760
I don't know the question, so there was so many things.

19:30.760 --> 19:33.760
I was a loss of it.

19:33.760 --> 19:37.760
If this one is translated into the last one, that was on the outside.

19:37.760 --> 19:43.760
So what kind of comparison do you see on this word in the last word?

19:44.760 --> 19:53.760
Oh, I think that you put feelings for you think it's completely different about what you're doing.

19:53.760 --> 19:55.760
And what's on the IUD side.

19:55.760 --> 19:56.760
Mm-hmm.

19:56.760 --> 20:00.760
The key perspective specifically for the configuration.

20:00.760 --> 20:04.760
How much of this kind of use is still for configuration,

20:04.760 --> 20:06.760
what do you do?

20:06.760 --> 20:08.760
Do I need to need the question?

20:09.760 --> 20:21.760
The question is, this model is a private sub-imperimentation.

20:21.760 --> 20:30.760
So, the short answer is, no, because this implementation depend on hardware security.

20:30.760 --> 20:37.760
So, how do Hsn or real bootloader?

20:37.760 --> 20:44.760
So, this model does not use virtualization.

20:44.760 --> 20:50.760
So, I guess the current server have to use virtualization.

20:50.760 --> 20:57.760
Virtualization needs some, have to say.

20:57.760 --> 21:01.760
So, I mean, no component that you have developed can be used for that use case.

21:01.760 --> 21:03.760
Like, if possible, some do not present.

21:03.760 --> 21:07.760
So, no component in your use case can be used in case.

21:07.760 --> 21:08.760
Oh, yeah, yeah, yeah.

21:08.760 --> 21:10.760
We can use all components.

21:10.760 --> 21:11.760
Yes, yeah.

21:11.760 --> 21:12.760
Okay.

21:12.760 --> 21:13.760
Okay.

21:13.760 --> 21:14.760
Okay.

21:14.760 --> 21:15.760
Okay.

21:15.760 --> 21:17.760
So, thank you very much.

21:17.760 --> 21:19.760
Thank you.

21:19.760 --> 21:29.760
Thank you.