Re: [flickertcb-devel] Flicker to support crypto token PAL

[Bryan P. <pa...@mi...>]

Hi Karsten,

Flicker is certainly a reasonable choice for creating a secure environment for a software crypto token.  In answer to your questions, on AMD, only 64KB of code and data are protected by default by the late launch operation (SKINIT).  If you want to use more than that, you need to write a small PAL that enables the DEV, hashes the rest of your code, and extends that measurement into the TPM.  The latter two operations are already supported in the existing Flicker code base, but you’d have to add the DEV operations yourself.  Intel will protect more by default, so that may influence your choice of platform.

At present, Flicker allocates approximately 112 KB of inputs and 112KB for outputs (see pal/params.h).  You can adjust those as needed, but you have to make corresponding adjustments to the kernel module as well, so everyone agrees where to find the IO.

We’ve seen better system stability using Flicker with Linux than with Windows.  On Linux, we’ve successfully run PALs for minutes with little or no problems, but we haven’t looked at it in great detail or at longer lengths.  Others on the list may be able to comment more.

All of the Flicker code is currently written assuming 32 bits, so I expect you’d have to do a nontrivial amount of work to update it to 64.  For example, you’d need to rewrite pal/asm.S for a 64-bit world.

Hope this helps.

-Bryan

From: Karsten Ohme [mailto:wid...@t-...]
Sent: Tuesday, April 28, 2015 1:12 PM
To: fli...@li...
Subject: [flickertcb-devel] Flicker to support crypto token PAL

Hi,

I would be interested in the current status of the project. My goal is to use a flicker for a soft token crypto library running on a untrusted OS (Windows and Linux). Is this a good fit?

  *   Are there issues with the memory footprint? To support a wide range of modes and algorithms several 100 kb are realistic.
  *   Is the input and output size restricted?
  *   Are there issues with long running PALs and the (non-)handling of interrupts?
  *   Support for 64 bit systems - what is the challenge here?

Best,
Karsten