11–20 of 22 posts
It's gonna be hard if you really want security. Card developers put a lot of effort into securing operations against sidechannel pertuberation, sidechannel and many more attacks, that opensource developers will hardly be able to handle on theeir own.
Here is a fully open secure hardware device: https://sc4.us/hsm/ (Please don't submit this link to HN. I want to stay somewhat stealthy until I've had a chance to write an introductory article.) At the moment it's only a prototype. I have done a very small production run, so if you want one to experiment with, contact me. I'm planning on doing a kickstarter to fund a real production run.
One thing that seems to be missing from your project is the actual "HSM-ness". Things like side channels and so probably are not relevant to the target market, but some kind of assurance that device's firmware was not tampered with is probably required.
So what measures does this "secure" C alternative offer against memory corruption to be positioned as better option than Java Card?!
It's based on public ARM specifications (MPU + service calls) so the attack surface is way smaller compared to a virtual machine and the performance is of course way better. Applications can still corrupt their own memory space temporarily (not rewrite their code) but can't touch other applications or the Operating System.
Here is a fully open secure hardware device: https://sc4.us/hsm/ (Please don't submit this link to HN. I want to stay somewhat stealthy until I've had a chance to write an introductory article.) At the moment it's only a prototype. I have done a very small production run, so if you want one to experiment with, contact me. I'm planning on doing a kickstarter to fund a real production run.
One thing that seems to be missing from your project is the actual "HSM-ness". Things like side channels and so probably are not relevant to the target market, but some kind of assurance that device's firmware was not tampered with is probably required.
Earlier quoted context omitted.
One thing that seems to be missing from your project is the actual "HSM-ness". Things like side channels and so probably are not relevant to the target market, but some kind of assurance that device's firmware was not tampered with is probably required.
Well side channel attacks should be very relevant for all projects involving security. And several similar projects have already been produced (see TREZOR, KeepKey in the Bitcoin space), based on a similar chip which is in my opinon not great for that kind of use case (the fuse protection mechanism is not certified, the chip doesn't offer any protection against active physical attacks and so on) - that's well explain…
Earlier quoted context omitted.
Well side channel attacks should be very relevant for all projects involving security. And several similar projects have already been produced (see TREZOR, KeepKey in the Bitcoin space), based on a similar chip which is in my opinon not great for that kind of use case (the fuse protection mechanism is not certified, the chip doesn't offer any protection against active physical attacks and so on) - that's well explain…
The SC4-HSM is not designed to be secure against physical compromise, but it can be made resistant against such attacks by encrypting the keys with a pass-phrase. This is not a perfect solution because the pass-phrase needs to be entered through a non-secure host, but it's better than nothing. An attacker would need to compromise the pass phrase and obtain physical possession in order to mount a successful attack.
Earlier quoted context omitted.
It's based on public ARM specifications (MPU + service calls) so the attack surface is way smaller compared to a virtual machine and the performance is of course way better. Applications can still corrupt their own memory space temporarily (not rewrite their code) but can't touch other applications or the Operating System.
So I don't see any benefit to go from possible logical errors to possible logical errors + memory corruption bugs.
Here is a fully open secure hardware device: https://sc4.us/hsm/ (Please don't submit this link to HN. I want to stay somewhat stealthy until I've had a chance to write an introductory article.) At the moment it's only a prototype. I have done a very small production run, so if you want one to experiment with, contact me. I'm planning on doing a kickstarter to fund a real production run.
The mentioned microcontroller has 192KiB of SRAM (including 64KiB of core-coupled memory).
Speaking of which, many programmers tend to ignore the CCM but it can be very useful (though it can't be accessed from other peripherals (timers, ADC, etc.) using the DMA).
It can be used for the heap and/or stack memories, for example, freeing up the remaining 128KiB for other purposes.
It can also be used for executing your code from the memory without using the flash which is faster and more energy-efficient.
Earlier quoted context omitted.
Well side channel attacks should be very relevant for all projects involving security. And several similar projects have already been produced (see TREZOR, KeepKey in the Bitcoin space), based on a similar chip which is in my opinon not great for that kind of use case (the fuse protection mechanism is not certified, the chip doesn't offer any protection against active physical attacks and so on) - that's well explain…
The SC4-HSM is not designed to be secure against physical compromise, but it can be made resistant against such attacks by encrypting the keys with a pass-phrase. This is not a perfect solution because the pass-phrase needs to be entered through a non-secure host, but it's better than nothing. An attacker would need to compromise the pass phrase and obtain physical possession in order to mount a successful attack.
Here is a fully open secure hardware device: https://sc4.us/hsm/ (Please don't submit this link to HN. I want to stay somewhat stealthy until I've had a chance to write an introductory article.) At the moment it's only a prototype. I have done a very small production run, so if you want one to experiment with, contact me. I'm planning on doing a kickstarter to fund a real production run.
> 32 kB RAM The mentioned microcontroller has 192KiB of SRAM (including 64KiB of core-coupled memory). Speaking of which, many programmers tend to ignore the CCM but it can be very useful (though it can't be accessed from other peripherals (timers, ADC, etc.) using the DMA). It can be used for the heap and/or stack memories, for example, freeing up the remaining 128KiB for other purposes. It can also be used for exec…