MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-2430-1412787377-1382.37410-5-0@isc.org>
References: <RT-Ticket-37410@isc.org> <543560E8.5070902@redhat.com> <rt-3.8.6-2430-1412785523-1286.37410-5-0@isc.org> <54356872.6040204@redhat.com> <rt-3.8.6-2438-1412786295-573.37410-5-0@isc.org> <rt-3.8.6-2430-1412787377-1382.37410-5-0@isc.org>
Message-ID: <5435741C.90104@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Organization: Red Hat
Subject: Re: [ISC-Bugs #37410] PKCS#11 PIN length is silently limited to 32 characters [patch]
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
Date: Wed, 08 Oct 2014 19:27:56 +0200
To: bind9-bugs@isc.org
Content-Transfer-Encoding: 7bit
From: Petr Spacek <pspacek@redhat.com>
RT-Message-ID: <rt-3.8.6-2416-1412789284-345.37410-0-0@isc.org>
Content-Length: 2013

On 8.10.2014 18:56, Francis Dupont via RT wrote:
>> I'm not opposing to that however I do not see a reason to artificially
>> limit PIN length on *client* side.
>
> => laziness... (i.e., it is more complex to manage
> a dynamically sized piece of memory :-).

That is why I used 1024 byte buffer :-)

I don't want to be bold but... aren't we spending too much time on such a 
minor thing?

Feel free to amend the buffer size or refuse the second patch completely if 
you feel that 31 byte PIN is good enough for everyone :-)

>> In this particular case I'm using SoftHSM so there is no secure way
>> how to
>> enforce limit on retries. That is the reason why I wanted to use very
>> long PIN.
>
> => a long PIN won't save you, in particular with SoftHSM
> which doesn't really protect it (BTW mainly because it can't
> in an easy way. I know how to reset the PIN in the case I used
> something which is not 1234 and I'd like to keep objects, and
> I did it more than once :-).

I'm not an SoftHSM expert but I have to ask:

Are you talking about SoftHSM v2? Looking at 
src/lib/data_mgr/SecureDataManager.cpp it seems that all values with 
CKA_PRIVATE = TRUE are encrypted with key which is derived from PIN.

Sure, it can't help against on-line attack where the key is in memory but it 
should help against off-line attacks.

Also, we want to run SoftHSM in separate process so bugs which allow attacker 
to read server's memory will not expose keys.

>> (And yes, I know that SoftHSM is really cheap HSM :-))
>
> => I added a large amount of code in SoftHSMv2 so now
> I am in its developer list! But if SoftHSM is a  very good tool
> to debug/practice/etc PKCS#11 code it was *not* designed
> for strong security at all.

I'm aware of that. Customers who want real security are encouraged to buy real 
HSM but SoftHSM is good enough for those who do not care.

SoftHSM should not be worse than keys stored in plaintext on disk, right?

Thank you for the discussion and your time!

-- 
Petr Spacek  @  Red Hat