Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tomu, a tiny ARM microprocessor which fits in your USB port

tomu.im

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#81

Post by pkaye »

vardump wrote: post #55
pkaye wrote: post #30

Earlier quoted context omitted.

Years back I used to work for a company that built 8051 clones. It was possible to prevent the microprocessor from reading the flash memory because the 8051 has a separate program memory and data memory space.

I don't understand how that helps to prevent reading anything. 8051 can read data from both CODE and XDATA memory spaces. See: http://www.keil.com/support/man/docs/is51/is51_movc.htm

Forgot to mention those two instruction will be disabled in flash protected mode.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#82

Post by bacon_waffle »

sametmax wrote: post #79
wahern wrote: post #74

Earlier quoted context omitted.

Other than registering multiple keys with a service (as others have explained), you can generate the private key off-device, import the key onto your device(s), then optionally delete the off-device key and/or archive it to external storage (e.g. disc stored in a safety deposit box at your bank).

So you can make duplicates as long as you generate the key offsite first ? Does it work with any hardare ?

At a basic level, the key is just a number, so there's no fundamental reason why it can't be duplicated.

However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked.

Copying keys would also imply that the secret information needs to pass between devices, which adds some combination of risk and complexity. If the key doesn't need to support copying, then the secret information could be generated inside, and never leave, the key.

It seems better if the permissions granted to unique keys are easy to replicate, rather than the keys themselves.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#83

Post by bsder »

PinguTS wrote: post #59
bsder wrote: post #15

Earlier quoted context omitted.

Newer microcontrollers like the Microchip(nee Atmel) SAM-L11 are implementing ARM TrustZone with hardware security features.

Secure as in CLKSREW?

CLKSCREW needs user mode DVFS (Dynamic Voltage and Frequency Scaling).

These don't exist on embedded processors like the one I referenced.

And, if someone has physical access, all bets are off.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#84

Post by mithro »

sannee wrote: post #73
microtherion wrote: post #66

Having bought a number of maker projects where the PCB is designed to plug into the USB port, like this one, I find that the mechanics generally don't work all that reliably. Not sure about the exact cause, maybe manufacturing tolerances on PCBs are not tight enough.

This looks like it's supported by a 3D printed enclosure. Otherwise I agree - you need >2.0mm thick PCB to prevent falling out and these are not offered by the usual cheap low-volume PCB manufacturers.

If you buy the Tomus from CrowdSupply (https://www.crowdsupply.com/sutajio-kosagi/tomu) it comes injection molded case designed by Sean 'xobs' Cross (who actually ran the campaign).

Doing plastics is well outside my skill set, so it was awesome to see him do that! xobs posted about the case here -> https://www.crowdsupply.com/sutajio-kosagi/tomu/updates/fina...

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#85

Post by wahern »

bacon_waffle wrote: post #82
sametmax wrote: post #79

Earlier quoted context omitted.

So you can make duplicates as long as you generate the key offsite first ? Does it work with any hardare ?

At a basic level, the key is just a number, so there's no fundamental reason why it can't be duplicated. However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked. Copying keys wou…

I agree that multiple unique keys are preferable.

But for traditional PKI schemes there's always at least one key (your personal master PGP key, your company SSH/X.509 CA) you want copies of, yet it's precisely the kind of key you absolutely want to keep off the network or within a secure hardware token; more so than authentication keys.

There are tokens that permit exporting (aka wrapping) a key for off-device storage or for transferring. If for transferring presumably you specify at key generation time a list of public keys to export to. But I've never used these tokens as the software was just too complex to bother with, proprietary, and poorly supported in the open source ecosystem. In the PGP world the typical advice (for better or worse) I've heard is to archive your master key on a disc and rotate your subkeys occasionally, necessitating brief exposure of your master key. Theoretically you would sign the subkeys from an old, non-networked computer.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#86

Post by utopcell »

keir-rex wrote: post #67
hasperdi wrote: post #61

Earlier quoted context omitted.

Could you share information of how one could do this? I looked it up on Github but could not find anything related to what you mentioned.

I think it might be related to this: https://hackaday.com/tag/logitech-unifying-receiver/

Indeed.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#87

Post by sametmax »

bacon_waffle wrote: post #82
sametmax wrote: post #79

Earlier quoted context omitted.

So you can make duplicates as long as you generate the key offsite first ? Does it work with any hardare ?

At a basic level, the key is just a number, so there's no fundamental reason why it can't be duplicated. However, other responses seem to be leaving out a discussion of why one would want to make identical keys in the first place. If you had identical keys, losing one would mean you'd need to revoke permissions of all copies. If the keys are instead unique, then only the lost key needs to be revoked. Copying keys wou…

> If you had identical keys, losing one would mean you'd need to revoke permissions of all copies

Makes sense. And also it means I can decide it's not part of my threat model and take the easy route. Thanks.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#88

Post by TrainsParent »

ggm wrote: post #37
MrMorden wrote: post #34

Earlier quoted context omitted.

Every keyboard has an MCU. They used to be 8051s, but now ARM (or PIC or AVR) is more likely.

Each time I do the OSX "need to reboot" thing and it sits at the equivalent of BIOS blowing driver updates for things like this, I think "yea, i hate BIOS, but at least I get told which devices are being re-coded" -with OSX, its a bit more opaque. "trust us"

echo "Now we're going to upgrade your storage capacity, please wait."

rm -rf /

Don't trust the status messages; they could be manipulated to anything, in practice. Counter-practice; I mean.

Re: Tomu, a tiny ARM microprocessor which fits in your USB port

#89

Post by CrazyPyroLinux »

ateesdalejr wrote: post #24
tlrobinson wrote: post #13

Earlier quoted context omitted.

A Yubikey clone where you have to tap out a passcode (morse code style) might be neat.

I would be concerned about the inherent audio security issues that solution might have...

Like one of these? onlykey.io
Post reply on HN