Comments 16
What kind of options is availible to buy it in Russian Federation? Do you have any distributors, resellers, etc there?
How do you prove that you are 'tamper evident'? May be some of your coders has decided to add a small undocumented feature to read seed value via a conveniently supported NFC protocol «Send 42 to dump all data».
Let's skip all tales of excellence and trust and start talking about open source.
Let's skip all tales of excellence and trust and start talking about open source.
'Tamper evident' means that it is not possible to discreetly open the case and access the chip, and has nothing to do with «secret NFC commands» (wiki- 'Tamper evident': «designed to reveal any interference with the contents»)
NFC can only be accessed from a relatively small distance (2-3 cm max), so if users worrying about «secret NFC commands» should keep their devices with them all the time.
NFC can only be accessed from a relatively small distance (2-3 cm max), so if users worrying about «secret NFC commands» should keep their devices with them all the time.
start talking about open source.what would open source change in this case? having the code open does not mean nobody can add a feature to read the seed, it is indeed the opposite, it will increase such risks.
The phrase 'Tamper evident' means that it can be used as a proof. «This site was accessed only by using THIS token». If someone can get out a seed value by hacking users NFS on their laptop, I see no point of token existence.
When I said 'open source' I literally mean 'open' 'source'. Not a libre licence. The source code of the product which is publicly available for audit, the reproducible build process and a verifiable binary content of the device ROM. It may come with any licence, but it should be open to public for inspection.
Openness is the single source of the trust in the modern computing.
When I said 'open source' I literally mean 'open' 'source'. Not a libre licence. The source code of the product which is publicly available for audit, the reproducible build process and a verifiable binary content of the device ROM. It may come with any licence, but it should be open to public for inspection.
Openness is the single source of the trust in the modern computing.
Apologies, but Token2 uses (and always used) «tamper-evident» in the context of «physical intervention evidence» (same as all other manufactures use this word).
the reproducible build process and a verifiable binary content of the device ROMI still do not get how this can protect from the «undocumented feature» risk you desribed in your previous comment. One can open-source everything, but how are you planning to verify that the final product you buy does not have such «undocumented features?»
How can you speak about 'physical intervention' if device is configurable via EM radiation? Any EM-capable device nearby may be used to completely obliterate any evidence in the device, install fake evidence or steal data to allow access while placing responsibility on the device owner (and saying that this is 'evidence').
Just imagine a POS terminal which allows you to use unprotected wireless shell to device to perform any operations (including firmware change). Do you think this device need to bother with any seals or 'tamper proofs'?
As soon as you have remote access capabilities you need to proof they can't be used to tamper device. If you don't any physical proofs is useless, as device acts as a proxy for remote attack.
Just imagine a POS terminal which allows you to use unprotected wireless shell to device to perform any operations (including firmware change). Do you think this device need to bother with any seals or 'tamper proofs'?
As soon as you have remote access capabilities you need to proof they can't be used to tamper device. If you don't any physical proofs is useless, as device acts as a proxy for remote attack.
Sorry, miss the question for validation.
As I said, reproducible builds solve the issue. We have a source code, which translates into the same binary code on each compilation (build). User can compile it by oneself to get the same binary. There is a way to get a copy of the binary firmware from the device to check if it's differ or not.
More details are here: wiki.debian.org/ReproducibleBuilds
As I said, reproducible builds solve the issue. We have a source code, which translates into the same binary code on each compilation (build). User can compile it by oneself to get the same binary. There is a way to get a copy of the binary firmware from the device to check if it's differ or not.
More details are here: wiki.debian.org/ReproducibleBuilds
Physical intervention — beyond the integrity of the original device. Literally, «no one else can put their chip inside our device without you (user) noticing it». That is the industry standard word we use.
Such devices are always a balance of security and user comfort. Let us take an example of using a TOTP protection with Gmail:
1) you can use an open source app on a smartphone (with Wifi/cellular connectivity) with all the risks of remote attacks etc. you name it
2) you can transfer the seed to C300 device via NFC and NFC is only accessible from within a short distance — so a Chineze* hacker would not have access to it as opposed to the case #1 — a potential attacker should sit in the same room
Regarding open source — all clear with open source software, but this does not work the same way with hardware. There are DIY open source OATH TOTP tokens, but if you want a compact and relatively cheap device with good battery life, such devices are inevitable to be produced at factories.
So, even if we provide reproducible builds (whatever it should be called in case of hardware) end users are not going to build the end products themselves. No doubt that factory produced devices have their own advantages, who would guarantee that the mass-production units will be exactly the same? I personally cannot imagine how to ensure the binary image you get from the device somehow (i.e. a usb port etc.) is really what is running on the device (i.e. there could be 2 firmware running in parallel) without opening the device itself
( * — Chineze — a fictional country)
Such devices are always a balance of security and user comfort. Let us take an example of using a TOTP protection with Gmail:
1) you can use an open source app on a smartphone (with Wifi/cellular connectivity) with all the risks of remote attacks etc. you name it
2) you can transfer the seed to C300 device via NFC and NFC is only accessible from within a short distance — so a Chineze* hacker would not have access to it as opposed to the case #1 — a potential attacker should sit in the same room
Regarding open source — all clear with open source software, but this does not work the same way with hardware. There are DIY open source OATH TOTP tokens, but if you want a compact and relatively cheap device with good battery life, such devices are inevitable to be produced at factories.
So, even if we provide reproducible builds (whatever it should be called in case of hardware) end users are not going to build the end products themselves. No doubt that factory produced devices have their own advantages, who would guarantee that the mass-production units will be exactly the same? I personally cannot imagine how to ensure the binary image you get from the device somehow (i.e. a usb port etc.) is really what is running on the device (i.e. there could be 2 firmware running in parallel) without opening the device itself
( * — Chineze — a fictional country)
You are insisting that NFC works only on short distances. Let's say the a phone with malicious app is in the same pocket as the token. Is this counts as a 'short' distance?
Do we really benefit from the physical security if adversary has a remove control over the device via a compromised third party appliance/application? The key advantage for any hardware token is that it's impossible to tamper the hardware with a software, and you proudly report that you allow that.
Do we really benefit from the physical security if adversary has a remove control over the device via a compromised third party appliance/application? The key advantage for any hardware token is that it's impossible to tamper the hardware with a software, and you proudly report that you allow that.
phone with malicious app is in the same pocket as the tokenthe risk is there in this case, to mitigate we propose to use NFC sleeves.
key advantage for any hardware token is that it's impossible to tamper the hardware with a softwarefully agree, but this question should not be addressed to us. Most of the systems do not allow importing the seeds, they generate randomly and show as a QR code. Our product is only a «workaround» to avoid having to use a mobile device (i.e. a smarphone) for TOTP.
P.S. Btw, we sell classic tokens as well.
I'm sorry but I think I didn't understood the main idea of NFC usage in this case. What kind of date is transfered via NFC?
The data transferred is the shared secret key (seed) used for TOTP generation (see tools.ietf.org/html/rfc6238#page-4 R5). This is needed for services not allowing to enter a custom seed, thus the only solution is to use a TOTP mobile app (like Google Authenticator).
NFC programmable TOTP tokens are «drop-in» replacements of the Google Authenticator-type applications
NFC programmable TOTP tokens are «drop-in» replacements of the Google Authenticator-type applications
Thanks) What about time sync? As far as I can see we should do this via NFC? Is there a Linux version of your app?
No time sync with this model. We have unrestricted* time sync feature with miniOTP-2 and are planning restricted** time sync with the next generation (C301 and miniOTP-3).
Linux version not available (yet). Currently only Android and Windows (10 64x) apps are planned to be released.
* the time can be set keeping the current seed
** setting the time will automatically clear the seed for security purposes (to avoid the risk of a replay attack)
Linux version not available (yet). Currently only Android and Windows (10 64x) apps are planned to be released.
* the time can be set keeping the current seed
** setting the time will automatically clear the seed for security purposes (to avoid the risk of a replay attack)
best article with nice information thank you
AWS Training in Hyderabad
Workday Training in Hyderabad Ameerpet
Sign up to leave a comment.
Programmable TOTP tokens in a key fob form-factor