Status? about freehsm

[adeck]

Oh damn. Well, yeah, this could actually be a lot of fun.
My background's CoE and CS, although as you may have noticed all the stuff I've done recently has been techops / dev ops.

For the next year I'm working and getting my master's degree, so I wouldn't have many cycles per week to burn on this, but... I could give like 3 hours a week. Nothing's done here, yet, so I'd need to start with the software PoC. Which means I'd need to look over the AES spec again.

But yeah. The general plan is:

• Start by implementing an algo in C to make sure you understand it,
• Exhaustively test that,
• Write it in hardware,
• Simulate all the same test cases as in software, ensuring the output is bit-for-bit identical to what the C algo gave,
• Write some input-output logic for an FPGA (the one I have is an XC3S200 breakout board; just pins and FPGA. I have a 16x2 LCD that I've been meaning to hook up)
• Make sure the thing behaves as expected on actual hardware (initially, just spot-check runs of bits. Once we've written something for actual bus connectivity, we can redo all the tests done in simulation. Something like ChipScope would be helpful here, but really we'd want something like USB or RS-232)

The first few things I can do where I am, but I don't have a lot of my hardware stuff with me because it's mostly on the other side of the continent.

What part would you want to start working on? And what kind of time commitment?
I feel like probably the most important thing to get done first is figure out coding conventions, project structure, deadlines, testing guidelines, that kind of thing.

[adeck]

Incidentally, would it be cool if I migrated documentation from my ansible-deployments repo to here? I feel like most of the stuff on issue tracking also applies here.

Oh! And are you cool with using Verilog? I can do either Verilog or VHDL, but... Verilog's just so much nicer.

[adeck]

Also, boom! You're now a collaborator. See how that happened? It was like magic. Don't mess it up by doing something silly like pushing directly to master or filling the wiki with racisms (that's rule no. 1 of the wiki right there; do not fill it with racisms).

[adeck]

There was also another guy I was going to work on this with who I kinda let down because was busy. But I should, and shall, contact him. Great guy. In IEEE; mainly works on robotics.

[adeck]

...And this might not be the best place for discussion. Created a #freehsm channel or freenode.
If you've used IRC before, you can use your favorite client. If not, here's the easy alternative:

https://webchat.freenode.net/

Could also use mibbit, I suppose. That's another web IRC proxy.

[evancox10]

1. 3 hours/week average is around what I could commit at this point in time.
2. I'm not 100% clear what you mean by "HSM," so probably the first thing to hammer out is the overall concept and what that would look like from a high level. HSM to me is something like this, which is mostly HW-accelerated assymetric encryption combined with boatloads of physical security. Whatever the concept is, however, I'm really just looking to get some experience in areas I haven't been able to at work, including git; agile concepts such as scrum, CI servers, unit tests, etc.; alternative/experimental programming- and HD-languages, e.g. Scala/Chisel, Vlang, SVUnit; and security algorithms/concepts. Been doing mostly low-level verilog/mixed-signal design and verification, and I've been wanting to work on some higher-level languages/concepts. Totally comfortable operating all the way down to circuit/transistor level too, however.
3. I have an old Digilent/Xilinx FPGA board, haven't used it since college but I'm thinking it should still work. I wouldn't mind investing in something like this, if necessary. I also would have some access to limited resources at work, such as soldering stations and bench equipment (scopes, PSUs, etc.)
4. Totally cool with wherever you want to put your documentation. Way I see it, what a person does with their own documentation is their own business, and not for me to question.
5. Darn, was really hoping I could spew my racisms here, but guess I'll have to find another place for that ¯_(ツ)_/¯
6. Verilog is fine. Haven't done VHDL in 5 years. SystemVerilog is basically VHDL at this point anyways, sans type checking.
7. Have a friend who MIGHT be interested too, I'll have to get in touch with him. His experience level with something like this is basically zero, but he's incredibly smart and very interested in privacy/security concepts.
8. Jumped on what I think is the right freenode IRC channel and I don't see anyone there. I haven't used IRC in ages though, so it's entirely possible I have no clue what I'm doing and could be in the wrong place. If so just message me on here or whatever. I do work full-time, so 9ish-7ish M-F isn't the best time for me to communicate.

[adeck]

Ah! Sorry about the IRC channel. I left at ~7 (Pacific time) since I assumed it was so late where you were you probably wouldn't want to talk then. Which brings us to another important point, I suppose; we should probably figure out what times we'll actually meet (and express all times with timezone suffixes, to make it easier).

In any case, I've realized using IRC probably wouldn't be the best, anyway. It doesn't have the concept of state or searchability, and besides I already use Slack for a bunch of other things. So I created a FreeHSM slack domain (freehsm.slack.com), and if you give me an e-mail address (since you'd need to post it in the comments, here, you'll probably want to obfuscate it or just create a new gmail or something explicitly for the purpose) I'll invite you to it.

Anyway, itemized response to your convenient ordered list:

1. Good stuff. Given how little time that is, one 20-minute (max) meeting (conference call) per week should actually let us cover everything.
2. Asymmetric encryption acceleration is one thing I'd want. Primarily, what I had in mind would be a module with support for the most common symmetric, asymmetric, block, and stream ciphers (maybe 5-10 in total; not bothering to actually support any which may be widely used, but are known to be flawed; so, no DES or RC4, for example). Less for application acceleration (although that is important) and more for key management and scheduling.

Essentially, I'm thinking of a magic box which can connect via USB or PCIe and which you give data to be encrypted / decrypted, and a separate hardware port (maybe a smartcard slot for a very simply formatted smartcard) used to enter keys. When a new smartcard is put in the slot the HSM reads the key and gives some indication (LED lit) as to whether the drive was detected in the slot, whether it was properly formatted (another LED), and a button that can be pressed to say "load the key on this card into HSM memory" and another three indicator LEDs for "registered button press", "key successfully loaded", and "key not successfully loaded".

At least initially, I'd steer clear of actually putting cert generation logic into the thing, because that would require sourcing entropy from somewhere, and I'm pretty sure I don't know how I'd even begin to vet such a system. That having been said, if we're both in on this, and you know how to gather entropy effectively, don't let me hold you back.

To ensure we know how to defend against more physical attacks (in case at some point anyone wants to fab any of this), we should probably do some reading. At least these (partly because they make for interesting reading, and partly because I don't know how hard it is to add those measures after-the-fact, and I don't want to find out everything needs rewriting after it's written + tested):

• http://soc.eurecom.fr/HWSec/l3/main.pdf
• http://www.grandideastudio.com/wp-content/uploads/secure_embed_paper.pdf

1. Ah, nice! At uni I have access to some old scopes which generally do pretty well. I might be willing to invest in an actual fully-fledge development board as well, but I won't do that until we actually need hardware. And we'd need to agree on the board (although the one you linked appears to have more than enough to make development easy).
2. "Way I see it, what a person does with their own documentation is their own business, and not for me to question." Well, yes and no. The foundational documentation will be about coding, documentation, issue tracking, and testing guidelines, to make it easier to do code reviews and maintain stuff, bring development time down, and make it easier for new people to join. As such it'd affect you just as much as it'd affect me. So, you'd need to read it and agree with it or suggest improvements.
3. Yay!

Putting in my three hours this week tonight, since I'll (counterintuitively) be less available this weekend.