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?
Listen, at this point, there is no fault/failure; I'm merely noodling around and learning and developing some keen interests in many aspects of pkcs. As a hardware guy, I'm just curious. Obviously many countries have clandestine programs to deeply inspect inside of silicon, GAN and many other types of materials, to the point of understanding things at a very low level. I'm not on that pathway; more or less taking a systems approach to characterize a billion cockroaches to develop strategies, just for me and my buds at gentoo user. No vision, just curiosity at this point. But, lately, the cat has jumped the Faraday cage so many different ways that it's hard to distinguish interlopers from true genius. ymmv. > >> 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? That would be pkcs#12 and such, no? Basic, diversified hardware explorations, hopefully without pissing any body off. Noodle around with hardware (pkcs#11) as well as tangents into the superfluous and minutia. Where ever the math takes me..... OK? >> 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. Those little proprietary vendor embedded security products have mostly been hacked, if you believe in fairy-dust, magic and bullshit. That said, with math, there is *always* a way around anything that man creates. ymmv. No, I'm not the goal-keeper, just an inquisitive old man. 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. Yep. Seen that one too, but nice pass. I wonder if it runs on a hardened embedded linux or a vendor stack of binaries. I'm not certain the vendor stacks have been robustly testing, if you consider the hardware tools available at a foundry labs run buy governments. In our limited world (without extraordinarily expensive hardware devices) it is probably secure. Graduate student kids a major universities, with some access, are mostly closely monitored. Perhaps a risc-V project that I missed somewhere, would be very enlightening? Surely a loosely related set of documents, links and wiki pages would allow noobs (like me) a place to dabble in the (gentoo) digital domain, thus posing no threat to anything but ignorance ? > You should read the technical explanations of the technology involved > and then ask specific questions. Excellent idea. I just was not certain, this gentoo user forum was amicable to these sorts of 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. Well put! Any working gentoo-embedded projects out their that moto (not sure who own imx now) hardware that is a good starting point for similar generic dev boards? >> 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, yes yes, very true. Asics and fpga are the common workaround by vendors. But if we fully characterize a plausible system, on processors/hardware with ample resources, then test/development platforms can facilitate mimicking and testing and great fun for the gentoo community, imho. Miniaturization, for PO-folks, is usually the last and most expensive efforts. A large (bloated) system, like a gentoo workstation, is often quite attractive during the full-characterization phase. > are uselessly complex, > or have nonfree components that undermine an estimate of their > security. Correct. That is by design. > 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. Can you characterize the (embedded) linux setup you proposed to use on that part? I'm not interested in compromising a vendors product, but rather full comprehension of the parts need to build these sort of pkcs centric systems. The assimilation into the public domain so that folks can use a wide variety of hardware to build something. The really keen interest for me is using (HPC) gentoo linux clusters to automate the pen testing of proposed devices and systems, over long intervals of time. AWS does not like folks pen testing any of their resources, and they are quite large in the IoT space. With that approach, I'm not sure anyone with drop of common sense would even use AWS for IoT activities? > 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. I have previously alluded to this tenet, somewhat:: What I think is needed is a common (gentoo) embedded linux platform to begin assembling the components necessary for a myriad of practical implementations of pkcs#11 devices, for the gentoo linux community. Once that (gentoo) embedded linux platform, materializes, evidence by a dozen or so participants, then hardening the tool chain would be the next step, say for AMD64 platforms. Then make it work on a (AMD64) workstation. Then a list of processors and dev boards for minimization and down-ports, more targeted. Then the component codes to what somebody wants to employ to build or test. More of a gentoo centric journey as oppose to nefarious pathways; hopefully will keep us out of jail? > Atmel/Microchip XMega > parts may be more suitable and do some with security of sorts, but are > still not as capable. You mean I cannot achieve a robust system, using a PicDem3? (Agreed ed.) > All FPGAs are either too large, too small, or > too costly, and in any case the synthesis tools and the cell layout > are proprietary. This means you have scoured the opencores and associated sites for such components? Have you searched out 'opensource cryptographic processors? I certainly have not performed the robust research and reading, yet. I'm looking for folks like mined and inquisitive who also have a large desire to avoid jail time. Some countries are totally against ordinary citizens developing these sorts of domain expertise. ymmv. Not to imply that the good folks of gentoo user are ordinary. Perhaps ordinary partial differential equation types of nerds, but certainly not ordinary. I do need to spend some time looking at resources you have others have pointed out. It's good to know some folks thinking about these sorts of things are moving forward. All large and most mid-sized corporations should have internal projects for such, as I think most vendor solutions are not too secure, from those with deep expertise or deep pockets or even deep packet inspection skills. > R0b0t1. James
