Re: [gentoo-user] pkcs#11

[R0b0t1]

On Tue, Jun 13, 2017 at 1:26 PM, james <garftd@×××××××.net> wrote:
> Hello one and all,
>
> I was looking at planet.gentoo.org and saw several (ultrabug) posts
> that involve pkcs#11; particularly related to the yubikey device.
> Looking around, there are SmartCards (SC) that be used in lieu of
> the Yubikey, and other schemes some with some without 2FactorAuth.
>

Can you provide a link for those? Is it just the Yubikey-style
authentication that is at fault, or their smartcard functionality as
well?

> Here is a source of 'Generic' SC::
> https://github.com/OpenSC/OpenSC/wiki/Supported-hardware-%28smart-cards-and-USB-tokens%29
>
>
> Has anyone a simple, basic implemention of pksc#11 ? That uses one of
> those Generic SC?
>
>
> I guess what I'm really looking for is a master list of ebuilds
> (overlays) that one has or possible could use to implement any form of
> PKCS#11 on a gentoo server, workstation, or embedded system? I've been
> googling on this a bit, but my keyword combos have not been very fruitful.
>

What are you trying to do with PKCS? Authenticate user accounts?

>
> Any of this on a gentoo-hardened profile?   Amd64 would be perfect
> but any processor/platform running any form of gentoo, would be keen.
> Work on another, like Debian or Arch would be of interest, too.
> Discussion or suggestions are most welcome, as this is not my normal
> area of interest. Any PCKS#11 (or as embodied in newer standards) usage
> on a gentoo cloud would be most exciting, for me.
>

Most things work by default on hardened, particularly if they don't
involve multimedia.


On Tue, Jun 13, 2017 at 4:41 PM, james <garftd@×××××××.net> wrote:
> On 06/13/17 14:40, Alon Bar-Lev wrote:
>> On 13 June 2017 at 21:26, james <garftd@×××××××.net> wrote:
>>
>> <snip>
>>
>>> I guess what I'm really looking for is a master list of ebuilds
>>> (overlays) that one has or possible could use to implement any form of
>>> PKCS#11 on a gentoo server, workstation, or embedded system? I've been
>>> googling on this a bit, but my keyword combos have not been very fruitful.
>>
>> Hi,
>>
>> You have at least these:
>>
>> https://packages.gentoo.org/packages/dev-libs/softhsm
>> https://packages.gentoo.org/packages/dev-libs/opensc
>> https://packages.gentoo.org/packages/dev-libs/opencryptoki
>> https://packages.gentoo.org/packages/app-crypt/coolkey
>>
>> Regards,
>> Alon
>>
>
>
> Yes thanks for the info above; and more using eix <-R|-cC> <dev-libs> |
> grep <pkcs|HSM> and other such searches.
>
>
> I should have been more detailed in my first post, apologies. I'm more
> or less looking for complete projects where someone at least moderately
> documented the steps, gotchas, nuances, etc etc. In theory, they're not
> too difficult. On the practical side, there's an ocean of fragmented
> minutia, depending on what you try, exactly. I guess I was look for a
> bit of a 'well worn' pathway, that included experimentation with the
> physical card side of things, gentoo centric. A book/website on
> practical pkcs#11  linux implementation?
>

You would probably be interested in https://inversepath.com/usbarmory.

You should read the technical explanations of the technology involved
and then ask specific questions.

>
> I also have look at some of the semiconductor vendor solutions, but
> there is little detail other than 'purchase' the interesting parts
> inside of fpga code or an asic, which does me no good. But implemented
> on an embedded microP with some  flexibility would be good, as long as
> the processor is one that also runs embedded (gentoo) linux. So any
> dev-boards (RaspPI-3 or ?) would be keen that have any sort of pkcs
> demo, I could purchase from a semiconductor vendor? Any ideas along that
> venue would also work for me.
>

This topic is probably a bit too specific for a vendor to have created
a demo board for it. You will find most parts have development boards,
most of them including some kind of USB connectivity. See above for an
example part - the part used for the USB Armory is interesting because
it supports what is essentially Secure Boot and you can ensure that
only signed code is run, barring expensive (~$1-10m) reverse
engineering of the processor's die.

>
> Perhaps some detail on hardening the platform, tool-chain and
> musl/ulibc/glibc as that's another fundamental part of the effort, I
> find scant info on. Codes bases such as this one in python [A] are
> interesting, but not complete. Basically trying to stand on the
> shoulders of folks that know what they are doing, and the CI or
> automated test best for penetration testing what you actually implement
> going forward, is another integral part of a complete solution.
>
>
> Theoretical or practical experience or just a good comprehensive
> document/book to read. Anything complete, not just a piece of code that
> is a fragment of a complete (FOSS?) pkcs#11 system? Gaining
> practical/working knowledge of these details seems to be fleeting, at
> least for me. I had just assumed in was a well-worn pathway, publically
> discuss in some detail. Perhaps a hacker/penetration forum, where the is
> expertise is what I seek?
>
>
> Are other folks interested in rolling their own solution, or am I
> pursuing an impossible DIYS project?
>

You're not alone but most of the devices that could implement what you
want are either underpowered and lack features, are uselessly complex,
or have nonfree components that undermine an estimate of their
security. My first attempt at wading through an NXP part's
documentation showed me it would take about a month before I had
anything useful that compiled.

For example those NXP parts that the USB Armory uses do not have a
easily to use toolchain and the header files are hard to obtain and
the example projects are nearly inscrutable. Atmel/Microchip XMega
parts may be more suitable and do some with security of sorts, but are
still not as capable. All FPGAs are either too large, too small, or
too costly, and in any case the synthesis tools and the cell layout
are proprietary.

R0b0t1.