Three Part Key Derivation

[atothRedHat]

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

[issue-label-bot]

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]

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]

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]

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]

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]

The agent registers itself when it boots ups.  No interaction is needed with anyone else.  The way that the agent discovers the registrar is either via config or via DNS mapping (i.e., keylime-registar.local or something).  The protocol that the agent runs with the registrar is secured directly (i.e., not with TLS).  It is possible for an attacker to man in the middle the registrar interaction.  No private information is leaked during this process.  An attacker *can* cause the node to register with the wrong registrar, but this will be detected later.  When the tenant and CV talk to the registrar, they use TLS so they can ensure they are talking to the right one.

…

-Nabil

-- Nabil Schear, Ph.D. Senior Staff, Secure Resilient Systems and Technology Group MIT Lincoln Laboratory, 244 Wood St, Lexington, MA 02420 Tel: 781-981-5744 Office: C-290F From: Luke Hinds <notifications@github.com> Reply-To: keylime/keylime-docs <reply@reply.github.com> Date: Thursday, May 2, 2019 at 9:28 AM To: keylime/keylime-docs <keylime-docs@noreply.github.com> Cc: "Schear, Nabil - 0553 - MITLL" <nabil@ll.mit.edu>, Mention <mention@noreply.github.com> Subject: Re: [keylime/keylime-docs] Three Part Key Derivation (#33) 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 It would be nice to have it in a flow chart / uml style, more than a presentation (google-doc, pptx) format. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[atothRedHat]

perfect will add that detail.

[jetwhiz]

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]

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