Date   

Re: Keylime next steps?

Alberto Planas Domínguez
 

El mié, 21 jul 2021 a las 20:40, Michael Peters (<mpeters@redhat.com>) escribió:

Answers inline:

On Wed, Jul 21, 2021 at 2:15 PM Alberto Planas Domínguez
<aplanas@gmail.com> wrote:
...
a) Are there plans to rewrite all the components of keylime in rust?

I saw that the agent is moving in that direction, and this makes sense. Seems that there are big missing bits still to do in the agent IIUC, like the double key distribution. Is the project also contemplating the rewrite for the verifier, the registrar, the CA and the rest of components?
There's been talk about some of this every now and then but nothing
concrete. For the server side, if it is ever rewritten I doubt it
would be in rust. I'm inclined to leave it as python as that is still
a good language target for the most contributions.
This makes sense too. For now I will work assuming that the server
plane have more live ahead, and so the changes there make sense.

b) The python code needs some refactoring. Are there plans to do that?
...
Personally I don't like big refactors just for refactoring. There
needs to be some other goal in mind. Like enabling some feature, or
making some bug-prone code more manageable. So there's no plans
strictly for refactoring, but if it happens as part of a new
feature/enhancement or a good code cleanup then we're definitely open
to it.
I understand. Checking #711 I saw some need for refactoring, but it
makes sense to do that only inside the context of the change alone.

c) How is the retro-compatibility managed?
...
With the new versioned API enhancement that should land soon we're
going to try and be more explicit about backwards compatibility. It
doesn't mean we can't break it but we need to do so in a measured and
documented way with versions supporting the transitions. You can see
the details here:
https://github.com/keylime/enhancements/blob/master/45_api_versioning.md
Thanks for the link!


Re: Keylime next steps?

Alberto Planas Domínguez
 

El mié, 21 jul 2021 a las 20:31, Luke A Hinds (<lhinds@redhat.com>) escribió:

Hi Alberto,

On Wed, Jul 21, 2021 at 7:15 PM Alberto Planas Domínguez
<aplanas@gmail.com> wrote:
...
a) Are there plans to rewrite all the components of keylime in rust?
...
I am more of the mind a go port of these might be more useful, but
it's ultimately not up to me.
I see, thanks. This helps me to understand that a rewrite is not in
the near horizon and investing time in improving the Python code makes
sense.

> agent IIUC, like the double key distribution.

I have not heard of these before, could you please expand?
Aha! Seems that I am reading the code and the commit history wrongly.

b) The python code needs some refactoring. Are there plans to do that?
...
Sure, this would be a good candidate for a keylime enhancement and
community discussion (you're doing the right thing here). It again
comes down to planning and having the resources to put hands on
keyboards to write the code. Upping unit test coverage would always be
welcome. We also need better integration tests.

https://github.com/keylime/enhancements
Somehow I neglected this repo. I see that there is a process to drive
the deep changes.

Thanks!!


Re: Keylime next steps?

Michael Peters
 

Answers inline:

On Wed, Jul 21, 2021 at 2:15 PM Alberto Planas Domínguez
<aplanas@gmail.com> wrote:

Hi o/

I am starting to experiment with keylime as a valid alternative for remote attestation inside the openSUSE MicroOS distribution. I contributed with some fixes recently and I have some others in the queue.
Thank you for your work so far and welcome to the community!

But I would like to ask some questions:

a) Are there plans to rewrite all the components of keylime in rust?

I saw that the agent is moving in that direction, and this makes sense. Seems that there are big missing bits still to do in the agent IIUC, like the double key distribution. Is the project also contemplating the rewrite for the verifier, the registrar, the CA and the rest of components?
There's been talk about some of this every now and then but nothing
concrete. For the server side, if it is ever rewritten I doubt it
would be in rust. I'm inclined to leave it as python as that is still
a good language target for the most contributions.

b) The python code needs some refactoring. Are there plans to do that?

I guess that this is related with the first question. Some bits of the codebase would need some [maybe big] refactoring, including a lot of tests. For example, for #711 we should have a single point of creating the agent object, but I am afraid of doing that without tests. Would make sense to attack this problem, making the tests and later the refactoring, or would be better to invest the resources in the rewriting?
Personally I don't like big refactors just for refactoring. There
needs to be some other goal in mind. Like enabling some feature, or
making some bug-prone code more manageable. So there's no plans
strictly for refactoring, but if it happens as part of a new
feature/enhancement or a good code cleanup then we're definitely open
to it.

c) How is the retro-compatibility managed?

Is OK to break the compatibility with older versions? I see some breaking changes over the history, and I guess that the rust agent will need some of them (like the async execute in the local_action python code) Do we have strict rules in this regard?
With the new versioned API enhancement that should land soon we're
going to try and be more explicit about backwards compatibility. It
doesn't mean we can't break it but we need to do so in a measured and
documented way with versions supporting the transitions. You can see
the details here:
https://github.com/keylime/enhancements/blob/master/45_api_versioning.md

Thanks,
--
Michael Peters


Re: Keylime next steps?

Luke A Hinds
 

Hi Alberto,

On Wed, Jul 21, 2021 at 7:15 PM Alberto Planas Domínguez
<aplanas@gmail.com> wrote:

Hi o/

I am starting to experiment with keylime as a valid alternative for remote attestation inside the openSUSE MicroOS distribution. I contributed with some fixes recently and I have some others in the queue. But I would like to ask some questions:

a) Are there plans to rewrite all the components of keylime in rust?

I saw that the agent is moving in that direction, and this makes sense. Seems that there are big missing bits still to do in the agent IIUC, like the double key distribution. Is the project also contemplating the rewrite for the verifier, the registrar, the CA and the rest of components?
It's been considered. The main element is planning the work out and
having contributors willing to undertake the work.

I am more of the mind a go port of these might be more useful, but
it's ultimately not up to me.

> agent IIUC, like the double key distribution.

I have not heard of these before, could you please expand?


b) The python code needs some refactoring. Are there plans to do that?

I guess that this is related with the first question. Some bits of the codebase would need some [maybe big] refactoring, including a lot of tests. For example, for #711 we should have a single point of creating the agent object, but I am afraid of doing that without tests. Would make sense to attack this problem, making the tests and later the refactoring, or would be better to invest the resources in the rewriting?
Sure, this would be a good candidate for a keylime enhancement and
community discussion (you're doing the right thing here). It again
comes down to planning and having the resources to put hands on
keyboards to write the code. Upping unit test coverage would always be
welcome. We also need better integration tests.

https://github.com/keylime/enhancements

c) How is the retro-compatibility managed?

Is OK to break the compatibility with older versions? I see some breaking changes over the history, and I guess that the rust agent will need some of them (like the async execute in the local_action python code) Do we have strict rules in this regard?
It really depends on what is being deprecated , but it certainly is
possible. For example, we deprecated TPM 1.2 not long back. This way
raised on the community meeting, an issue was then raised and no
objections were made so we removed it.


Thanks.


Keylime next steps?

Alberto Planas Domínguez
 

Hi o/

I am starting to experiment with keylime as a valid alternative for remote attestation inside the openSUSE MicroOS distribution. I contributed with some fixes recently and I have some others in the queue. But I would like to ask some questions:

a) Are there plans to rewrite all the components of keylime in rust?

I saw that the agent is moving in that direction, and this makes sense.  Seems that there are big missing bits still to do in the agent IIUC, like the double key distribution. Is the project also contemplating the rewrite for the verifier, the registrar, the CA and the rest of components?

b) The python code needs some refactoring. Are there plans to do that?

I guess that this is related with the first question.  Some bits of the codebase would need some [maybe big] refactoring, including a lot of tests.  For example, for #711 we should have a single point of creating the agent object, but I am afraid of doing that without tests. Would make sense to attack this problem, making the tests and later the refactoring, or would be better to invest the resources in the rewriting?

c) How is the retro-compatibility managed?

Is OK to break the compatibility with older versions? I see some breaking changes over the history, and I guess that the rust agent will need some of them (like the async execute in the local_action python code) Do we have strict rules in this regard?

Thanks.


Re: Security Advisory: CVE-2021-3406

Luke A Hinds
 

On Wed, Feb 24, 2021 at 2:31 PM Michael Peters <mpeters@redhat.com> wrote:

Hello Keylime Community,

A security issue was discovered in the Keylime agent and registrar
that breaks the cryptographic chain of trust from the Endorsement Key
certificate to agent attestations.

This means that when a TPM 2 is in use on the agent, there is no way
to know whether the quotes are produced by a valid TPM.

This issue has been assigned CVE-2021-3406

Affected Versions:
All versions after Keylime v3.0.0

How do I mitigate this vulnerability?
ACTION REQUIRED: Upgrade to 6.0.0
Prior to upgrading, this vulnerability can be mitigated by not using
TPM 2 on the agent.

Upgrade steps:
Shutdown the verifier, registrar and all agents.
Perform upgrade to version 6.0.0 (database migration is included in the release)
Start up all services, registrar, agent and verifier
Update the agents using the keylime_tenant command `-c update`

Further notes: The 6.0.0 release also introduces the deprecation of
TPM 1.2 and the deep quote function, as per issues #526 and #530

Advisory Notice:
https://github.com/keylime/keylime/security/advisories/GHSA-78f8-6c68-375m

Acknowledgements:
This vulnerability was reported and fixed by Keylime team member
Patrick Uiterwijk.

--
Michael Peters
Keylime (Project Lead)






Re: Security Advisory: CVE-2021-3406 -> suggestions

Michael Peters
 

Ken,

You can see more details from Patrick about the flaw and the fix used here: https://patrick.uiterwijk.org/blog/tpm2-attestation-keylime-vulnerability and yes it's mostly "don't send redundant data" :)

On Wed, Feb 24, 2021 at 9:50 AM Kenneth Goldman <kgoldman@...> wrote:

Is there a way to comment on this in github? I could not find a way other than starting a new issue.

I would suggest (and what I implemented)

1 - Do not verify the EK pub against the EK cert. Just don't send the EK pub at all. Use the value from the EK cert.

2 - Do not verify the AIK name against the AIK pub. Rather, don't send the AIK name at all. Calculate it from the AIK pub.

In general, don't send redundant data. Each instance opens an attack surface if a check is omitted. It's better security to eliminate the redundancy than add checks.

--
Ken Goldman kgoldman@...
914-945-2415 (862-2415)


"Michael Peters" ---02/24/2021 09:23:05 AM---Hello Keylime Community, A security issue was discovered in the Keylime agent and registrar

From: "Michael Peters" <mpeters@...>
To: keylime@groups.io
Date: 02/24/2021 09:23 AM
Subject: [EXTERNAL] [keylime] Security Advisory: CVE-2021-3406
Sent by: main@keylime.groups.io





Hello Keylime Community,

A security issue was discovered in the Keylime agent and registrar
that breaks the cryptographic chain of trust from the Endorsement Key
certificate to agent attestations.

This means that when a TPM 2 is in use on the agent, there is no way
to know whether the quotes are produced by a valid TPM.

This issue has been assigned CVE-2021-3406

Affected Versions:
All versions after Keylime v3.0.0

How do I mitigate this vulnerability?
ACTION REQUIRED: Upgrade to 6.0.0
Prior to upgrading, this vulnerability can be mitigated by not using
TPM 2 on the agent.

Upgrade steps:
Shutdown the verifier, registrar and all agents.
Perform upgrade to version 6.0.0 (database migration is included in the release)
Start up all services, registrar, agent and verifier
Update the agents using the keylime_tenant command `-c update`

Further notes: The 6.0.0 release also introduces the deprecation of
TPM 1.2 and the deep quote function, as per issues #526 and #530

Advisory Notice:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keylime_keylime_security_advisories_GHSA-2D78f8-2D6c68-2D375m&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=HonjSJGoDsDXKXwtZvZFyAVKSujtARRFPmnPRayJsTU&s=uQthwd4oeApM-2DceX4GIwXpzWizRkMrQBrlMPf1758&e= 

Acknowledgements:
This vulnerability was reported and fixed by Keylime team member
Patrick Uiterwijk.

--
Michael Peters
Keylime (Project Lead)










Re: Security Advisory: CVE-2021-3406 -> suggestions

Kenneth Goldman
 

Is there a way to comment on this in github? I could not find a way other than starting a new issue.

I would suggest (and what I implemented)

1 - Do not verify the EK pub against the EK cert. Just don't send the EK pub at all. Use the value from the EK cert.

2 - Do not verify the AIK name against the AIK pub. Rather, don't send the AIK name at all. Calculate it from the AIK pub.

In general, don't send redundant data. Each instance opens an attack surface if a check is omitted. It's better security to eliminate the redundancy than add checks.

--
Ken Goldman kgoldman@...
914-945-2415 (862-2415)


"Michael Peters" ---02/24/2021 09:23:05 AM---Hello Keylime Community, A security issue was discovered in the Keylime agent and registrar

From: "Michael Peters" <mpeters@...>
To: keylime@groups.io
Date: 02/24/2021 09:23 AM
Subject: [EXTERNAL] [keylime] Security Advisory: CVE-2021-3406
Sent by: main@keylime.groups.io





Hello Keylime Community,

A security issue was discovered in the Keylime agent and registrar
that breaks the cryptographic chain of trust from the Endorsement Key
certificate to agent attestations.

This means that when a TPM 2 is in use on the agent, there is no way
to know whether the quotes are produced by a valid TPM.

This issue has been assigned CVE-2021-3406

Affected Versions:
All versions after Keylime v3.0.0

How do I mitigate this vulnerability?
ACTION REQUIRED: Upgrade to 6.0.0
Prior to upgrading, this vulnerability can be mitigated by not using
TPM 2 on the agent.

Upgrade steps:
Shutdown the verifier, registrar and all agents.
Perform upgrade to version 6.0.0 (database migration is included in the release)
Start up all services, registrar, agent and verifier
Update the agents using the keylime_tenant command `-c update`

Further notes: The 6.0.0 release also introduces the deprecation of
TPM 1.2 and the deep quote function, as per issues #526 and #530

Advisory Notice:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_keylime_keylime_security_advisories_GHSA-2D78f8-2D6c68-2D375m&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=HonjSJGoDsDXKXwtZvZFyAVKSujtARRFPmnPRayJsTU&s=uQthwd4oeApM-2DceX4GIwXpzWizRkMrQBrlMPf1758&e= 

Acknowledgements:
This vulnerability was reported and fixed by Keylime team member
Patrick Uiterwijk.

--
Michael Peters
Keylime (Project Lead)










Security Advisory: CVE-2021-3406

Michael Peters
 

Hello Keylime Community,

A security issue was discovered in the Keylime agent and registrar
that breaks the cryptographic chain of trust from the Endorsement Key
certificate to agent attestations.

This means that when a TPM 2 is in use on the agent, there is no way
to know whether the quotes are produced by a valid TPM.

This issue has been assigned CVE-2021-3406

Affected Versions:
All versions after Keylime v3.0.0

How do I mitigate this vulnerability?
ACTION REQUIRED: Upgrade to 6.0.0
Prior to upgrading, this vulnerability can be mitigated by not using
TPM 2 on the agent.

Upgrade steps:
Shutdown the verifier, registrar and all agents.
Perform upgrade to version 6.0.0 (database migration is included in the release)
Start up all services, registrar, agent and verifier
Update the agents using the keylime_tenant command `-c update`

Further notes: The 6.0.0 release also introduces the deprecation of
TPM 1.2 and the deep quote function, as per issues #526 and #530

Advisory Notice:
https://github.com/keylime/keylime/security/advisories/GHSA-78f8-6c68-375m

Acknowledgements:
This vulnerability was reported and fixed by Keylime team member
Patrick Uiterwijk.

--
Michael Peters
Keylime (Project Lead)


Docker error #cal-invite

jamshed.memon@...
 

Hi,

I tried to run the docker environment, but facing a problem when selecting the option for tpm 1.2 or tpm2.0. When selecting a or b i am getting error 

"/bin/bash: /root/keylime/.ci/test_wrapper.sh: no such file or directory 
failed to resize tty, using default size"

it would be great if you can help.


Updated Event: Keylime bi-weekly meeting #cal-invite

main@keylime.groups.io Calendar <noreply@...>
 

Keylime bi-weekly meeting

When:
Wednesday, 13 January 2021
4:30pm to 5:00pm
(UTC+00:00) Europe/London
Repeats: Monthly on the second Wednesday

Where:
https://cloud-native.slack.com/archives/C01ARE2QUTZ

Organizer: axel simon axel@...

Description:
Keylime bi-weekly meeting, where the community discusses ongoing issues, pull requests and anything Keylime-related.
The meeting happens on the second and fourth Wednesday of every month, this is calendar event is for the second Wednesday meeting.


Event: Keylime bi-weekly meeting #cal-invite

main@keylime.groups.io Calendar <noreply@...>
 

Keylime bi-weekly meeting

When:
Wednesday, 27 January 2021
4:30pm to 5:00pm
(UTC+00:00) Europe/London
Repeats: Monthly on the fourth Wednesday

Where:
https://cloud-native.slack.com/archives/C01ARE2QUTZ

Organizer: axel simon axel@...

Description:
Keylime bi-weekly meeting, where the community discusses ongoing issues, pull requests and anything Keylime-related.
The meeting happens on the second and fourth Wednesday of every month, this is calendar event is for the fourth Wednesday meeting.


Event: Keylime bi-weekly meeting #cal-invite

main@keylime.groups.io Calendar <noreply@...>
 

Keylime bi-weekly meeting

When:
Wednesday, 13 January 2021
4:30pm to 5:00pm
(UTC+00:00) Europe/London
Repeats: Monthly on the second Wednesday

Where:
https://cloud-native.slack.com/archives/C01ARE2QUTZ

Organizer: axel simon axel@...

Description:


PTL step down and election

Luke A Hinds
 

Hello All,

I will be stepping down as PTL to give someone else a try. I still plan to be 100% involved in the project, it's more about making our community democratic and not having me become a bleeding deacon :)

I also made a proposal for Michael Peters to become the new PTL, but at the same time anyone can propose an existing MAINTAINER be put forward as PTL.


Cheers,

Luke


Re: ERROR MEASUREMENT SHA01

Luke A Hinds
 

Hi Danilo,

Is your machine a hardware node with a real TPM or are you using a container / virtual machine?

I would recommend jumping in our slack channel if you can, you should get more immediate help in there:


The channel name is #keylime

Cheers,

Luke

On Wed, Oct 14, 2020 at 7:42 AM Danilo Queiroga <daniloqueiroga10@...> wrote:
Hello, I’m an IT student and I’m developing an article about TPM.  I followed the steps of the tutorial on the keylime.dev page but I have a problem measuring the boot_aggregate with the SHA01 with value settled as zero when running this command head -5 / sys / kernel / security / ima / ascii_runtime_measurements

Thank you in advance and I await the answer.

Machine: ubuntu 18.04.5
Steps:  1.0 Install Ansible.
1.1 - sudo apt-get update
1.2 - sudo apt-get install git
1.3 - sudo apt-add-repository ppa:ansible/ansible
1.4 - sudo apt update
1.5 - sudo apt install ansible

2 - Install Keylime.
2.1 - git clone https://github.com/keylime/keylime.git
2.2 -  cd keylime/
2.3 - sudo ./installer.sh


ERROR MEASUREMENT SHA01

Danilo Queiroga <daniloqueiroga10@...>
 

Hello, I’m an IT student and I’m developing an article about TPM.  I followed the steps of the tutorial on the keylime.dev page but I have a problem measuring the boot_aggregate with the SHA01 with value settled as zero when running this command head -5 / sys / kernel / security / ima / ascii_runtime_measurements

Thank you in advance and I await the answer.

Machine: ubuntu 18.04.5
Steps:  1.0 Install Ansible.
1.1 - sudo apt-get update
1.2 - sudo apt-get install git
1.3 - sudo apt-add-repository ppa:ansible/ansible
1.4 - sudo apt update
1.5 - sudo apt install ansible

2 - Install Keylime.
2.1 - git clone https://github.com/keylime/keylime.git
2.2 -  cd keylime/
2.3 - sudo ./installer.sh


Next Keylime meeting: Wednesday 16 Sep, 15:30 UTC (in 25 min)

axel simon
 

Hi everyone,
We are restarting the Keylime weekly meetings, with the next one happening today, Wed 16 September at 15:30 UTC (that's 16:30 BST, for those in the UK).

All are welcome, no matter your level of involvement.

When:
--------
15:30 UTC

Where:
---------

Agenda:
-----------

See you there!

axel
--
axel simon
member of technical staff, security & blockchain
Office of the CTO
Red Hat ☎ +33 (0)1 41 91 81 40 www.redhat.com


Restarting Keylime meetings – next meeting Tuesday 8 September 16:30 GMT

axel simon
 

Hi everyone,
We will be restarting the Keylime weekly meetings, with the next one happening Tuesday 8 September (that's tomorrow) at 16:30 GMT.
We will see if we keep the same time slot for the future, especially if it doesn't suit the community.

All are welcome, no matter your level of involvement.


See you there!

axel

--
axel simon
member of technical staff, security & blockchain
Office of the CTO
Red Hat ☎ +33 (0)1 41 91 81 40 www.redhat.com


Release v5.7.0

Luke A Hinds
 

Hello All,

I just cut release v5.7.0

Please note for this release onwards, we are now licensed under the Apache 2.0 from the previous BSD-Clause 2.
  • Remove unused config loading in registrar 610565d
  • Fix for registrar and verifier running on different hosts db53181
  • Incorrect text of verifier, should be agent 0b9fbb5
  • Move major service entry & cli into keylime/cmd 7a927a8
  • Perform clean up and archive old items b940b4a
  • Catch regex exception for invalid exclude list e4d49a9
  • Move db & tpm layers to separate directory c323ae5
  • Fixes requests to reactivate agent causes verifier exception 9451127
  • Agent can just "use" an already created EK 550f554
  • Switch popen.wait() for popen.communicate() 160ac2b

Best Regards

Luke


Re: Q: Is an agent's policy automatically re-enabled upon agent restart (i.e. machine reboot)?

Luke A Hinds
 

I have created an enhancement proposal for this work:


I am also (as you would have noticed) introducing a new means of proposing significant changes in Keylime. This is loosely based on Kubenetes Enhancement Proposals (KSP). It means we can review , track and gather enhancement proposals in one single location. So this will replace the old system of using Google Docs (which is not fair on those who do not wish to use google based tools).

If you have an existing enhancement proposed still in flight, please port over to the new format.

If you see any improvements that could be made to this new enhancement proposal , you're welcome of course to make a pull request.

More details are on the README:


It's a sunday morning effort, so go easy on the mistakes :)

On Sat, Apr 18, 2020 at 9:02 PM Luke A Hinds <lhinds@...> wrote:
Thanks Ken, that's what I thought and we are using the ibm tpm (1119).

I will try to test this and we can plan out a means for the agent to recommence verification once it's back online again.

On Sat, Apr 18, 2020 at 8:54 PM Kenneth Goldman <kgoldman@...> wrote:

It depends on the emulator and version.

I recall that the original Microsoft implementation 'remanufactured' the TPM when the process started. It may be different now. The IBM implementation retains the TPM NV state in NVChip unless the -rm (remove, remanufacture) option is used.

Of course, like the HW TPM, powerup and startup affect the state.

--
Ken Goldman kgoldman@...
914-945-2415 (862-2415)


"Luke A Hinds" ---04/18/2020 02:29:50 PM---Hi Charlie, I guess this would only be the case for a HW tpm, could we test this with

From: "Luke A Hinds" <lhinds@...>
To: "Munson, Charles - 0553 - MITLL" <Charles.Munson@...>
Cc: "main@keylime.groups.io" <main@keylime.groups.io>
Date: 04/18/2020 02:29 PM
Subject: [EXTERNAL] Re: [keylime] Q: Is an agent's policy automatically re-enabled upon agent restart (i.e. machine reboot)?
Sent by: main@keylime.groups.io





Hi Charlie,

I guess this would only be the case for a HW tpm, could we test this with the emulator. I figure as long as NVChip is not delete and the tpm_server is not started with the clear state flag?

_,_._,_




--
Luke Hinds: Security Strategy  | Office of the CTO | Red Hat
e: lhinds@... | t: +44 12 52 36 2483



--
Luke Hinds: Security Strategy  | Office of the CTO | Red Hat
e: lhinds@... | t: +44 12 52 36 2483

1 - 20 of 150