Re: [gentoo-user] pkcs#11

[james]

On 06/13/17 23:07, R0b0t1 wrote:
> 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?

Opensc website lists national and generic Smart card information.

>
>> 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?

Implement pkcs#11 using/testing a variety of schemes with various IoT
devices, like printers

https://twitter.com/flashman/status/871896475902631936

>
>>
>> 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.

Every used 'DPI' or deep packet inspection or similar tools? Just look
at embedded systems from 10 years ago; many are compromised. The modern
(IoT) devices that use MQTT are even more hacked.  Got to defcon
and poke around a bit....

>
>
> 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.
>
>