On 06/13/17 23:07, R0b0t1 wrote: > On Tue, Jun 13, 2017 at 1:26 PM, james <gar...@verizon.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 <gar...@verizon.net> wrote: >> On 06/13/17 14:40, Alon Bar-Lev wrote: >>> On 13 June 2017 at 21:26, james <gar...@verizon.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. > >
