Re: [opencryptoki-users] What does 'CKA_EXTRACTABLE' actually mean?

[Grzegorz S. <gst...@gm...>]

Hi Osama,

Thanks for the reply. I don't really understand how the keys could be
used if I remove them from the disk. The certificate for the key is
presented when connection parameters are negotiated, so as I see it,
the private key needs then to be used to encrypt/decrypt the
(symmeric) session key -- in other words, the private key neess to be
available to the client software (OpenVPN, wpa_supplicant etc) so that
encypted connections can be set up. If I remove it, the certificate
will advertise a key I won't be able to use to set up encrypted
connections.

As I understand it, when I use the "TPM token" via openCryptoki, the
private key of the new generated RSA key pair is stored on disk (under
/var/lib/opencryptoki/tpm/[username]), but it's encrypted itself using
one of the secure keys stored in the TPM chip -- otherwise the "TPM
token" wouldn't be different from a relatively insecure software
token. The key is then decrypted using the TPM key whenever it needs
to be used.

So, the trivial attack, as in "I get elevated privileges and snatch
the /var/lib/opencryptoki/tpm files to clone the TPM token" shouldn't
work, because the private key would be encrypted by keys from _this_
particular TPM chip and wouldn't work on another computer. And
wouldn't even work for another user on the same computer without the
user PIN number.

This is how I see the situation: the CKA_EXTRACTABLE flag only means
that you can set up a migration process as the TPM owner to transfer
the key to another computer/TPM chip, having it securely encrypted all
the way. To me, that's very different from "just take the file if you
can and you've just extracted the key". Essentially, the extraction
itself is a separate process that needs to be arranged by the TPM chip
owner and happens at the "tpm-tools" level (or lower), that is, below
the PKCS#11 API that openCryptoki provides.

I wrote to the list to confirm that my understanding of the above is
correct, or change it if it's incorrect, If I'm wrong about the
security of the solution, the project will be stopped -- and has to be
stopped, to minimize the risk of security breaches. So, this is pretty
important to me. You're the only one to have replied so far, the list
actually looks a bit like a tumbleweed and dust place. Which is odd,
given that TPM-based security is certainly on the radar in a lot of
places.

Unfortunatly, I don't have any programmers' time assigned to the
project, it's just a test rollout of Linux desktops, and our devs time
is precious. I've posted to the -tech list as well, no reply from
there either. Thanks for your time anyway,

Best,
Greg

On 28 September 2016 at 12:24, Osama Farrag <of...@gm...> wrote:
> Greg
>
> There is TPM based security, except it is not the best mode of TPM security.
> if the key files are not on the disk then the clone attack vector is no
> longer a concern; however, to fully address your project requirements, you
> have to modify the source code of opencryptoki to make the key
> non-migrate-able instead the currently hard coded setup. if you have
> budget/time to do it, You should make the changes such that users of
> opencryptoki be allowed through command line options, or configuration file,
> to choose at the time of token/key generation to type of key
> non-migrate-able, current default setting. This way each user can determine
> decide what they need. This what should have been done in the first place.
> There are also improvements needed; for example currently have certain
> assumptions regarding password values that should be configurable to support
> same defaults -z that TPM trousers assume. These will minimize difficulties
> for many users.
>
> Best,
> Osama
>
> On Wed, Sep 28, 2016 at 4:55 AM, Grzegorz Staniak <gst...@gm...>
> wrote:
>>
>> Hi Osama,
>>
>> That's actually very bad news to me, as TPM-based security is a
>> pre-condition of the  project: if I can't get the setup to work with
>> TPM, there will be no Linux laptop rollout at all. I haven't been able
>> to find an alternative to openCryptoki as far as securing certificates
>> and exposing them via PKCS#11 is concerned, so if not this, it's
>> nothing.
>>
>> Thanks for your help, anyway.
>>
>> Best,
>> Greg
>>
>> On 27 September 2016 at 18:35, Osama Farrag <of...@gm...> wrote:
>> > Greg;
>> >
>> > Cloning the token is a feasible attack vector, given how openCryptoki
>> > elected to implement TPM support; (hard code the type of keys TPM will
>> > produce). The documents they provide recognizes this risk and recommend
>> > that
>> > key material to be removed/copied outside the host ideally to a machine
>> > not
>> > connected to a network.
>> >
>> > Please send an email when your blog site is up.
>> >
>> > Best regards
>> > Osama Farrag
>> >
>> > On Tue, Sep 27, 2016 at 6:44 AM, Grzegorz Staniak <gst...@gm...>
>> > wrote:
>> >>
>> >> Hi Osama,
>> >>
>> >> I'm not using CentOS or Red Hat (we went for Ubuntu LTS), and I'm not
>> >> using OpenSSL either. I create a CSR using the "certtool" utility from
>> >> the GNU TLS package, sign it on another system using the regular SSL
>> >> CA setupo, then send it back and import into the "TPM token" using
>> >> regular PKCS#11 tools (p11tool). I haven't got a detailed step-by-step
>> >> write-up yet, but a blog entry is planned after I have all the setup
>> >> in place,
>> >>
>> >> I agree that key migration is crucial for data protection, but in my
>> >> case the keys used for wifi/vpn certificates can be provisioned again
>> >> if lost or compromised, so I'm much more concerned about the
>> >> possibility of "cloning" the virtual token. Is that a feasible vector
>> >> o attack? What do I need to do to actually extract a private key from
>> >> the TPM token and can this be done by the user if they have root
>> >> access? I'm trying to research TPMs in more depth at the moment, but
>> >> that's a broad subject. Can anyone advise?
>> >>
>> >> Best,
>> >> Greg
>> >>
>> >> On 26 September 2016 at 19:14, Osama Farrag <of...@gm...> wrote:
>> >> > Greg;
>> >> >
>> >> >
>> >> > I am interested to know how you were able to get these parts working
>> >> > of
>> >> > “OpenCryptoki”? I am trying to get TPM keys to be signed by CA, but
>> >> > was
>> >> > not
>> >> > able to setup OpenCryptoki to work with openSSL to generate CSR. I
>> >> > understand the limitations/weakness caused by current approach taken
>> >> > by
>> >> > OpenCryptoki designers.
>> >> >
>> >> >
>> >> > They should allowed users to select the type of key (with
>> >> > non-migratble
>> >> > as
>> >> > an option); I think they were trying to simplify recovery of keys to
>> >> > a
>> >> > new
>> >> > platform. They recommend that token removed from platform hard disk,
>> >> > may
>> >> > be
>> >> > archived on media. I think recovery of Identity Key is not necessary
>> >> > because
>> >> > new key and certificate can be generated at a new platform. Not all
>> >> > keys
>> >> > are
>> >> > storage keys, and as such  ease of migration should be a users
>> >> > choice.
>> >> >
>> >> >
>> >> > Again, I hope that you have detailed steps for setting this for
>> >> > CentOS
>> >> > linux
>> >> > distribution.
>> >> >
>> >> >
>> >> > Thanks
>> >> >
>> >> > Osama Farrag
>> >> >
>> >> > The johns Hopkins University
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> >
>> >> > From: Grzegorz Staniak <gst...@gm...>
>> >> >
>> >> > Date: Monday, September 26, 2016 at 6:12 AM
>> >> >
>> >> > To: "ope...@li..."
>> >> > <ope...@li...>
>> >> >
>> >> > Subject: [opencryptoki-users] What does 'CKA_EXTRACTABLE' actually
>> >> > mean?
>> >> >
>> >> >
>> >> > using the
>> >> >
>> >> > tpm_tok backend, a CSR generated with the keys using 'certtool',
>> >> >
>> >> > signed externally, imported back into the "TPM token" with consistent
>> >> >
>> >> > names and IDs, almost ready for deployment.
>> >> >
>> >> >
>> >> > My only worry is that when I list the objects in the token, the
>> >> >
>> >> > private key comes up flagged as:
>> >> >
>> >> >
>> >> > CKA_WRAP/UNWRAP; CKA_PRIVATE; CKA_EXTRACTABLE;
>> >> >
>> >> >
>> >> > I've found some info on the net that said openCryptoki generates
>> >> >
>> >> > "extractable" keys only. Taken literally, this signals a problem,
>> >> >
>> >> > since at least theoretically it  means someone could clone the "TPM
>> >> >
>> >> > token". On the other hand, no standard PKCS#11 tool I've found allows
>> >> >
>> >> > that, exactly because it defeats the purpose of a token, TPM-based or
>> >> >
>> >> > not.
>> >> >
>> >> >
>> >> > Could someone please answer the question from the subject to clear
>> >> >
>> >> > this up? Is a TPM-token key extractable using the PKCS#11 API, or
>> >> >
>> >> > otherwise? Can I prevent this using TPM tools? Thank you,
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Grzegorz Staniak <gstaniak [at] gmail _dot_ com>
>> >
>> >
>>
>>
>>
>> --
>> Grzegorz Staniak <gstaniak [at] gmail _dot_ com>
>
>



-- 
Grzegorz Staniak <gstaniak [at] gmail _dot_ com>