Security assessment is a bottom-up process. Most security in a HSM is in the hardware. This is clearly not using secure IC's as illustrated in the smartcard market. It's already going to hit a ceiling there. Let's look at the datasheet anyway to see what can be built on foundation of STM32F415. Keep in mind I rarely deal with MCU's or embedded stuff. Some questions or concerns will come from my memory loss or lack of experience.
http://www.st.com/content/ccc/resource/technical/document/da...
Embedded flash 512KB or 1MB for programs and data. Checked with a CRC unit. There's some kind of accelerator between flash memory and main bus. Effects on security or robustness unknown. The flash might be writeable to attacker, esp since it's flash not ROM. What protections are here to prevent that?
Embedded SRAM. Up to 192KB of system SRAM w/ up to 64KB of CCM data RAM. Has 4KB backup SRAM "only accessible from CPU... content protected against unwanted write accesses, and retained in Standby or VBAT mode." First, what does "protected against unwanted" mean specifically? Second, does HSM software properly overwrite new memory, check pointers, do periods processing, and so on to prevent leaks via requests from host or compromise of subsystem?
Memory protection unit. Simplified MMU splits memory into 8 areas with 8 sub-areas ranging from 32 bytes to 4GB addressable memory. Access control typically managed by RTOS. Does HSM properly use MPU to isolate keys, cryptographic functions, kernel, and non-security critical software? What's the TCB size and assurance activities that went into the component that manages this?
DMA controller. Two units do what DMA always does: bypass all checks for raw speed. Configured by software. Attacks on that code or anything that can reference it might lead to DMA attacks. Curious what effect attack on host, esp a driver, could have far as divulging the MCU's secrets to a malicious program on the host.
Interrupts. Can compromised host flood the device for DDOS or use them selectively to extract keys via glitch in interrupt handling? Doing just the flooding while otherwise doing nothing could also be used to trick users into thinking device is unreliable. They might use less confidential method as backup.
"The boot loader is located in system memory. It is used to reprogram the Flash memory by
using USART1 (PA9/PA10), USART3 (PC10/PC11 or PB10/PB11), CAN2 (PB5/PB13), USB OTG FS in Device mode (PA11/PA12) through DFU (device firmware upgrade)." This is a pile of stuff embedded people probably recognize. All I know is it needs exploration to help determine exposure to boot- or flash-level attacks.
"The 4-Kbyte backup SRAM is an EEPROM-like memory area. It can be used to store data which need to be retained in VBAT and standby mode." This could be useful for long-term, key storage. The flash filesystems are harder to overwrite since they put data all over the place to reduce wear on individual components. Overwriting this is... with my limited memory... more straight-forward. It also preserves availability. To prevent thieves extracting, the keys might be encrypted before storage using a function that combines onboard-software, something entered through the host, and/or something done via buttons on drive. If host app deletes its secrest after use, then a simple snatch-and-grab won't work.
Watchdog timers. These are useful in high-security to deal with HW- & SW-level failures in the "known unknowns" and "unknown unknowns" categories. Maybe set a watchdog during important, cryptographic operations that should be done in certain timerange and/or for system operation in general. If it activates, any secrets are cleared immediately then user must recover device. Basically, "Fail Safe, Hard, and Noticeably" principle in action given who knows what led to watchdog activating. Catch all.
"Secure digital input/output interface" I got unnecessarily excited: it was just SDcard support. Oh well. :)
"USB controller... Internal USB DMA." The USB section doesn't tell me enough to know the risks it might have. Depends on what software directs it, what access it has to what memory, and so on. Then, we can at least see where the checks have to be put or what code has to be perfect. The DMA part was in "high-speed" section but not "full-speed." So, add DMA concerns above to USB subsystem and code if HSM uses high-speed. Possibly if full-speed if DMA stays on and accessible anyway where designers just assume people wouldn't try to use it rather than force that to be true.
"embed a cryptographic accelerator" This always concerns me as I have trust issues with these. Let's say we trust them. I'd apply all the tests available for these. Past that, do security at interface design-by-contract style plus extra code review to make sure they're used correctly. Guttman's security kernel in cryptlib is a nice example. Also mentions it supports DMA request generation. If it's always on, then add DMA considerations to the protocol engine that uses these.
"delivers 32-bit random numbers generated by an integrated analog circuit" Have at least one unit doing nothing but outputing analog noise all day for weeks. Run all randomness tests on the whole set plus subsets of it to see if statistical properties change significantly during specific periods of time. This is good practice in general to assess effectiveness. However, especially important with analog in case they chose shitty noise source that varies with environmental factors. I recall Bitbabbler lead says they keep a whole pile of them doing this since first prototypes to keep sample size statistically significant itself. That approach is even better if one has resources to do it.
JTAG and embedded trace macrocell. Well, these are always interesting from an attacker perspective. :) Maxim says there's no security once it's in their physical possession. Let's not make it easy, though. A basic mitigation here is requiring user to activate it with their password, PIN or some button presses. Lacking that, anything the software sees indicating unauthorized access can lead to nuking the secrets. Should stop majority of attackers who are casual or script kiddies. Part of that backup 4K SRAM might be used to keep track of anomolies that otherwise disappear with power turned on and off due to attacker experimenting.
So, that's the hardware. It has potential, as smartcards illustrate, to perform the job at hand with numerous risks that must be assessed and countered. Anything on host that configures, does requests through, or interrupts it is a security threat to be mitigated somehow. Protocol engines need sanity checks plus coded in a way to be amenable to any and all forms of static/dynamic analysis. MPU should compartmentalize secrets & kernel from the rest. Long-term keys can be stored in flash and/or backup SRAM with SRAM having some advantages. Other SRAM overwritten after use, including memory for intermediate steps. Any onboard registers overwritten during context switch (periods processing) to untrusted code. Ops take fixed time with careful attention to shared memory/resources to mitigate timing channels. Make damn sure they can't corrupt the boot code. I still don't know exactly how that's installed or protected from software attack. Need help from MCU or embedded people here.
The system level I'm unclear on as lisper hasn't given me full use-case list. The basic is to make sure keys are generated properly, used properly, never see host and trustworthy TRNG. These can be met with above methods if identified risks are knocked out or turn out not a concern. Security-oriented IC's, as found in EAL5+ or EAL6+ smartcards, are much more suited to this stuff as they put in more effort into HW mitigations and assurance of TCB implementation. Ledger Blue wallet uses an EAL6+ IC as an example. Consider using one of them in future version of product. Additionally, pull up MCU errata page to look at any CPU errata in specific product causing crashes or weird execution. Especially on MPU. Malware & smart pentesters used those in the past.
Emanation or HW-level attacks will still work on this device due to no mitigations. That means one use-case, using it on untrustworthy computers in public, cannot be performed with this device in event person's secrets are high-value to Five Eyes, Israeli, or Russian intelligence services known to use those attacks plus any high-end contractors that can do the same. Security researchers are also publishing more over time, which means blackhats will eventually use them. An associate pointed out that one of the designs for card computer (Bitcoin?) used red-black separation in PCB itself to a degree to reduce cryptozone's ability to electrically effect untrusted zone. Physical Red-Black was used by military for decades to reduce leaks. Cheaper solutions like those might be used to reduce impact a bit but users should be warned this risk remains for high-value targets.
So, that's my brief review of this product at just the hardware and system levels. I haven't looked at the app level to determine if how it's used or implemented meets the criteria. There's risks there, too. Might look into them. For now, I think lisper has plenty to think about on the hardware & implementation side of things. He will be busy. :)