Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Three Part Key Derivation #33

Open
atothRedHat opened this issue May 2, 2019 · 9 comments

Comments

4 participants
@atothRedHat
Copy link

commented May 2, 2019

issue to capture Three Part Key Derivation (TPKD) flow to add to documentation and presentations

@issue-label-bot

This comment has been minimized.

Copy link

commented May 2, 2019

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.83. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

@atothRedHat

This comment has been minimized.

Copy link
Author

commented May 2, 2019

Three Part Key Derivation:
-Tenant tells registrar to add the new node to its database
-Tenant generates the nodes boot key (K_b) and encrypts node config data (which includes the nodes private key and Certificate from the CA) with it
-Tenant splits K_b into two pieces U and V
-Tenant send V to Verifier and keeps U
-Agent of the node creates ephemeral boot key pair
-Agent of the node sends tenant and verifier its’ ephemeral public key (NK)
-Tenant and Verifier encrypt U and V respectively with the node’s NK
-Tenant and Verifier send individual attestation requests to the node’s Agent
-Agent responds back to each request with it’s attestation quote
-If the quote is valid (TPM signing checks out) the generator of the request will send their half of K_b to the Agent
-Once the Agent receives both U and V, it decrypt them with its’ private key and recombinds them into K_b and decrypts the configuration data assigned to the node.

@atothRedHat

This comment has been minimized.

Copy link
Author

commented May 2, 2019

so the one phase I'm missing is how/when does the agent register itself? is it after the tenant tells the registrar to add it to it's table or is it when it agent node initially boots (which would mean that the registrar endpoint would be given in clear init data, which I think was mentioned but I could be dreaming things like that at this point :-])

@atothRedHat

This comment has been minimized.

Copy link
Author

commented May 2, 2019

from meeting chat log (for reference):

Andrew Toth
@atothRedHat
11:34
I have the following written up (which I'll turn into an animation)
Three Part Key Derivation:
-Tenant generates the nodes boot key (NK) and signs node config data with it
-Tenant splits NK into two pieces U and V
-Tenant send V to Verifier and keeps U
-Agent of the node sends tenant and verifier its’ public key
-Tenant and Verifier encrypt U and V with the node’s public key
-Tenant and Verifier send individual attestation requests to the node’s Agent
-Agent response back to each request with it’s attestation quote
-If the quote is valid (TPM signing checks out) the generator of the request will send their half -of NK to the Agent
-Once the Agent receives both U and V, it decrypt them with its’ private key and recombinds them into NK and decrypts the configuration data assigned to the node.
The one thing I'm questioning is if the agent actually sends it's public key to both the tenant and the verifier or if it is committed to the registrar sometime before and the Tenant and Verifier pull it from there
Nabil Schear
@nabilschear
11:36
the boot key we call k_b
NK is a different key
Luke Hinds
@lukehinds
11:36
I think the meeting is over anyhow, so go for it with the above..sounds like something good to get on paper.
Charlie
@jetwhiz
11:37
sends its private key to the tenant/verifier?
Andrew Toth
@atothRedHat
11:37
@nabilschear , exactly why I wanted to get eyes on it before presenting it :-)
sorry public
let me edit that question for posterity
Nabil Schear
@nabilschear
11:39
hold on @atothRedHat
Andrew Toth
@atothRedHat
11:42
holding.....
Nabil Schear
@nabilschear
11:44
sorry, getting help on exercise
ok, so K-B can be used to sign and or encrypt data that should be securely delivered to the node
Andrew Toth
@atothRedHat
11:44
no worries, that's what make gitter meetings nice :-)
Nabil Schear
@nabilschear
11:44
k_b gets split into u and v
When you say "public key" above
Andrew Toth
@atothRedHat
11:46
ah and rereading your comments in the issue, nk is the agents public key
Nabil Schear
@nabilschear
11:46
that's NK
yep
Andrew Toth
@atothRedHat
11:47
ok, I'll make the change
Nabil Schear
@nabilschear
11:47
the public key NK gets sent to the tenant/verifier along with the quote response
NK is ephemeral. only used once
the registrar doesn't know about it
Andrew Toth
@atothRedHat
11:48
good note thanks,I'll try to comment on that during the talk
ok so other thatn the key names, is the rest of the explaination ok?
Nabil Schear
@nabilschear
11:49
many of these interactions happen all once
there's one http interaction between tenant and verifier
there's then 2 http interactions (request resp pairs) between tenant->agent
and cv -> agent
Luke Hinds
@lukehinds
11:51
@atothRedHat , please document what you learn if you can..put it up for review for feedback from @nabilschear / @jetwhiz
call it 'Three Part Key Derivation overview' or the like
https://github.com/keylime/keylime-docs
Andrew Toth
@atothRedHat
11:52
yep, was going to be part of the plan :-)
@nabilschear is that described somewhere (and I missed it or misinterpreted it)?
Nabil Schear
@nabilschear
11:54
it's in various slides
the acsac ones and the ones i sent via email have this in detail
Andrew Toth
@atothRedHat
11:55
so I misinterpreted :-) it happens
ok so parts the flow happens in parallel but the gist is correct?
Nabil Schear
@nabilschear
11:58
well the things that can happen parallel are these:
the tenant->agent interaction can happen any time
the tenant->cv interaction happens before the cv->agent interaction
well, all of these need to happen after the agent->registrar interaction
Andrew Toth
@atothRedHat
11:59
that's the part I'm missing and wanted to include
Nabil Schear
@nabilschear
12:00
first is the agent->registrar
tenant can then call cv and agent in parallel (it doesn't, i think it does cv, but it can do in parallel)
once the cv gets called, it then calls the agent, calls the registrar, adn then calsl the agent again
same for tenant. one rest call to agent, one rest call to registrar, one rest call to agent
Andrew Toth
@atothRedHat
12:03
so the detail I'm missing is what is being accomplished with each registrar interation
Nabil Schear
@nabilschear
12:03
ok, theres' two different things that the registrar does
the agent talks to the registrar to bind its attestation key to its endorsement key
Andrew Toth
@atothRedHat
12:04
so that's the first interaction above
Nabil Schear
@nabilschear
12:04
and then the tenant and cv then just ask the regisrar what attestation key is associated with the node
Andrew Toth
@atothRedHat
12:05
ok, figured out a bit of my fog (always interchanging agent and tenant in my thought process)
Nabil Schear
@nabilschear
12:05
that's the agent->registrar interaction does the key binding
the tenant/cv interaction with the registrar is just to get the bound key for the node
Andrew Toth
@atothRedHat
12:06
I thought I had heard that the tenant register the node
Nabil Schear
@nabilschear
12:06
an unfortunate overlaod of the word register
Andrew Toth
@atothRedHat
12:06
ah
Nabil Schear
@nabilschear
12:06
the tenant tells the verifier about the node
Andrew Toth
@atothRedHat
12:07
ok, to let it know it should expect the node communication
Nabil Schear
@nabilschear
12:07
we shouldn't use the register
word
Andrew Toth
@atothRedHat
12:07
yep, notify maybe
or not
we'll work on it :-)
Nabil Schear
@nabilschear
12:08
adding it to its database

@lukehinds lukehinds added this to To do in Keylime via automation May 2, 2019

@lukehinds

This comment has been minimized.

Copy link
Contributor

commented May 2, 2019

so the one phase I'm missing is how/when does the agent register itself? is it after the tenant tells the registrar to add it to it's table or is it when it agent node initially boots (which would mean that the registrar endpoint would be given in clear init data, which I think was mentioned but I could be dreaming things like that at this point :-])

If we start up the agent on its own you see the connection init in the stack trace:

Using config file /etc/keylime.conf
2019-05-02 13:21:58.859 - keylime.tpm - WARNING - INSECURE: Keylime is using a software TPM emulator rather than a real hardware TPM.
2019-05-02 13:21:58.859 - keylime.tpm - WARNING - INSECURE: The security of Keylime is NOT linked to a hardware root of trust.
2019-05-02 13:21:58.859 - keylime.tpm - WARNING - INSECURE: Only use Keylime in this mode for testing or debugging purposes.
2019-05-02 13:21:58.859 - keylime.tpm2 - INFO - Taking ownership with config provided TPM owner password: keylime
2019-05-02 13:21:59.201 - keylime.tpm2 - INFO - TPM Owner password confirmed: keylime
2019-05-02 13:21:59.201 - keylime.tpm2 - INFO - Flushing old ek handle: 0x81000000
2019-05-02 13:22:00.277 - keylime.tpm2 - WARNING - No EK certificate found in TPM NVRAM
2019-05-02 13:22:00.278 - keylime.tpm2 - INFO - Flushing old ak handle: 0x81000001
2019-05-02 13:22:02.770 - keylime.cloudagent - INFO - Agent UUID: D432FBB3-D2F1-4A97-9EF7-75BD81C00000
Traceback (most recent call last):
  File "/usr/bin/keylime_agent", line 11, in <module>
    load_entry_point('keylime==1.2', 'console_scripts', 'keylime_agent')()
  File "/usr/lib/python2.7/site-packages/keylime-1.2-py2.7.egg/keylime/cloud_agent.py", line 519, in main
    keyblob = registrar_client.doRegisterAgent(registrar_ip,registrar_port,agent_uuid,tpm_version,ek,ekcert,aik,ek_tpm,aik_name)
  File "/usr/lib/python2.7/site-packages/keylime-1.2-py2.7.egg/keylime/registrar_client.py", line 139, in doRegisterAgent
    context=None)
  File "/usr/lib/python2.7/site-packages/keylime-1.2-py2.7.egg/keylime/tornado_requests.py", line 38, in request
    response = http_client.fetch(request)
  File "/usr/lib64/python2.7/site-packages/tornado/httpclient.py", line 118, in fetch
    self._async_client.fetch, request, **kwargs))
  File "/usr/lib64/python2.7/site-packages/tornado/ioloop.py", line 581, in run_sync
    return future_cell[0].result()
  File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 260, in result
    raise_exc_info(self._exc_info)
  File "<string>", line 3, in raise_exc_info
socket.error: [Errno 111] Connection refused

So it happens in keylime/registrar_client.py in the function doRegisterAgent and it tries to connect to the registrar first.

It would be nice to have it in a flow chart / uml style, more than a presentation (google-doc, pptx) format.

@nabilschear

This comment has been minimized.

Copy link

commented May 2, 2019

@atothRedHat

This comment has been minimized.

Copy link
Author

commented May 2, 2019

perfect will add that detail.

@jetwhiz

This comment has been minimized.

Copy link
Member

commented May 2, 2019

Three Part Key Derivation:
-Tenant tells registrar to add the new node to its database
-Tenant generates the nodes boot key (K_b) and encrypts node config data (which includes the nodes private key and Certificate from the CA) with it
-Tenant splits K_b into two pieces U and V
-Tenant send V to Verifier and keeps U
-Agent of the node creates ephemeral boot key pair
-Agent of the node sends tenant and verifier its’ ephemeral public key (NK)
-Tenant and Verifier encrypt U and V respectively with the node’s NK
-Tenant and Verifier send individual attestation requests to the node’s Agent
-Agent responds back to each request with it’s attestation quote
-If the quote is valid (TPM signing checks out) the generator of the request will send their half of K_b to the Agent
-Once the Agent receives both U and V, it decrypt them with its’ private key and recombinds them into K_b and decrypts the configuration data assigned to the node.

This looks good to me. A few points (which are maybe a little pedantic):

  • "encrypts node config data (which includes the nodes private key and Certificate from the CA) with it"
    • the tenant (software) will encrypt whatever payload was provided to it by the tenant (user), which may include CA certificates, etc. The payload could be nearly anything though, including shell scripts to auto-run and sensitive configurations.
  • "If the quote is valid (TPM signing checks out) "
    • There is a bit more to checking the validity of the quote than just checking that it was correctly signed (especially with IMA enabled). The big thing though is comparing the included PCR values to a known-good whitelist.
@atothRedHat

This comment has been minimized.

Copy link
Author

commented May 3, 2019

Thanks Charlie, good notes. I definitely didn't mean to inadvertently mislead, so I'll update wrt those points

@atothRedHat atothRedHat closed this May 3, 2019

Keylime automation moved this from To do to Done May 3, 2019

@atothRedHat atothRedHat reopened this May 3, 2019

Keylime automation moved this from Done to In progress May 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.