Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Kenneth Goldman]

James Bottomley  wrote on 
02/10/2017 11:46:03 AM:

> > quote: 810 milliseconds
> > verify signature: 635 milliseconds
> 
> Part of the way of reducing the latency is not to use the TPM for
> things that don't require secrecy: 

Agreed.  There are a few times one would verify a signature inside the 
TPM,
but they're far from mainstream:

1 - Early in the boot cycle, when there's no crypto library.

2 - When the crypto library doesn't support the required algorithm.

3 - When a ticket is needed to prove to the TPM later that it verified
the signature.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Kenneth Goldman]

> > It does. My trusted keys implementation actually uses sessions.
>
> But as I read the code, I can't find where the kernel creates a
> session.  It looks like the session and hmac are passed in as option
> arguments, aren't they?

A bit of background.

In TPM 1.2, any authorization needed a session and an HMAC.

In TPM 2.0, authorization can be done using a plaintext password
(optionally) rather than an HMAC.  To me, kernel authorization
is a good use case for a plaintext password, since there is a
trusted path to the TPM.

When using a plaintext password, the caller does not require
startauthsession.  There is a special handle number that means
"plaintext password, no HMAC".  It's always available, and does
not occupy a session slot.

However, for the future ...

TPM 2.0 also has policy sessions.  E.g., use of the EK requires
a policy.

If the kernel ever wants to use policy, it needs startauthsession.

That's why I'm thinking that perhaps the space code should just
reserve ~2 sessions for it's own use, so it never blocks
because user space has occupied all the session slots.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Kenneth Goldman]

> > quote: 810 milliseconds
> > verify signature: 635 milliseconds
> 
> Part of the way of reducing the latency is not to use the TPM for
> things that don't require secrecy: 

Agreed.  There are a few times one would verify a signature inside the 
TPM,
but they're far from mainstream:

1 - Early in the boot cycle, when there's no crypto library.

2 - When the crypto library doesn't support the required algorithm.

3 - When a ticket is needed to prove to the TPM la

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

[Kenneth Goldman]

On Thu, Feb 09, 2017 at 12:04:26PM -0700, Jason Gunthorpe wrote:
Jarkko Sakkinen  wrote on 02/10/2017
03:48:37 AM:

> > This series should focus on allowing a user space RM to co-exist with
> > the in-kernel services - lets try and tackle the idea of a
> > policy-restricted or unpriv-safe cdev when someone comes up with a
> > comprehensive proposal..

First, does "coexist" mean in series (two layers of RM) or in parallel
(both
have simultaneous access).

Or does "in-kernel services" not include an RM?

Assuming in series, it will complicate the lower RM.  The main issue,
as always, is session context.  If you permit the upper RM to save context,
the lower RM has to track the mapping, because the lower layer can
alter the saved session context (regapping).
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

[Kenneth Goldman]

"Dr. Greg Wettstein"  wrote on 01/04/2017 11:12:41 
AM:

> The kernel needs a resource manager.  Everyone needs to think VERY
> hard and VERY, VERY carefully about what gets put into the kernel.  In
> making a decision, put the ABSOLUTE smallest amount of code into the
> kernel ...

If you're a TCG member, I invite you to join the TSS WG.  I'd like
an ally for simplicity.
 
> Repeat incessantly to oneself, TPM1.2 and TPM2 are only similar by
> virtue of sharing three ASCII characters.

:-) I have to remember that one!

But, to be accurate, the hardware interface is nearly compatible, and
the high level concepts (key hierarchy, authorization, PCRs, BV space) 
are similar.  The API and implementation are new.

> DO NOT rush this process.  If we do not get this right we will
> ultimately end up trying to shove something which is conceptually
> worse then tss/tscd into the kernel.

The (only?) reason to put any of this in the kernel is that the kernel
also needs access to the TPM. 

> Pay homage to Ken, his TSS2 and TPM2 simulator work are beyond
> excellent...

Thank you.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [Ibmtpm20tss-users] [TrouSerS-tech] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Kenneth Goldman]

Trimmed the CC list a bit.  Where does this discussion really belong? 
Trousers is for TPM 1.2,
and it's not a TSS or TPM device driver issue.

If you're all TCG members, the TCG's TPM WG is the real place to go if you 
want to get 
something fixed.

James Bottomley  wrote on 
01/03/2017 06:22:56 PM:

> > 
> > [Note, I haven't looked closely at TPM2, but TPM1.2 has a concept of
> >  key usage, and I assume that is carried over in the below comments]
> 
> The TPM1.2 all uses the correct signing functions, the problem is only
> with 2.0.
> 
> > I think it is very important to natively support the sign-only key
> > usage restriction. TPM1.2 goes so far as to declare keys that can be
> > used for arbitary decrypt as 'legacy do not use'.

TPM 2.0 has several features to support this:

- Signing keys, a usage restriction that can only sign.
- Policy only, with a policy restricted to specific commands, e.g., Quote 
or Sign.
- Restricted keys, that have a fixed algorithm and can only sign TPM 
generated data.

What it doesn't have is the ability (for a signing key) to prepend a 
caller
specified OID and padding.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] add TPM2 version of create_tpm2_key and libtpm2.so engine -> Hash algoritms

[Kenneth Goldman]

Jason Gunthorpe  wrote on 01/04/2017 
01:54:34 PM:

> We don't need the algorithm in the TPM. We just need to be able to RSA
> sign an arbitary OID + externally computed hash like TPM 1.2 could.
> 
> What is the recommended way to create a key with a sign-only intent
> that can be used with arbitary OID + computed hash?

Probably the long-term correct way is to go to the TCG and ask for a 
new feature.  However, this is (often certified) hardware, so the turn 
around is likely to be a year.

> James is proposing using the Decrypt op to do this job.

That works.  I've coded it.  However, the key doesn't have
"sign only intent", in that the caller not only provides the OID
but also provides the padding.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Re: [tpmdd-devel] [Ibmtpm20tss-users] add TPM2 version of create_tpm2_key and libtpm2.so engine -> Hash algoritms

[Kenneth Goldman]

James Bottomley  wrote on 01/04/2017 02:45:21 PM:

> > James is proposing using the Decrypt op to do this job.
> 
> I believe the TCG has decided this is the only way to sign arbitrary
> data.

My suspicion is that this was an omission, not a decision.  In fact,
Part 1 explicitly describes a caller provided OID.  It just wasn't
implemented - yet.


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel