3 ms·

That's a very disingenuous summary. It seems impossible to make the device open due to the NDAs. Can you explain how they would get around these? With regards

by rrego 10y ago

That's a very disingenuous summary. It seems impossible to make the device open due to the NDAs. Can you explain how they would get around these? With regards to the applet manager, that seems to be an issue with customer friction less so than being too hard. While "crypto nerds" would be fine, business applications could be affected.

dublinben 10y ago
Not using hardware components that would require NDAs would be the obvious alternative.
- sgift 10y ago
  Obvious? As in "I didn't read the post, didn't read that there are only two suppliers for this kind of hardware and didn't read that both of them require this NDAs"-obvious? Quote for your convenience: So — why not combine the best of two worlds then, i.e. using secure hardware in an open-source design? There are a few problems with that: - There is an inverse relationship between making a chip open and achieving security certifications, such as Common Criteria. In order to achieve these higher levels of certifications, certain requirements are put on the final products and their use and available modes. - There are, in practice, only two major players providing secure silicon and none of their products/platforms are available on the open market for developers except in very large volumes. - Even for large volume orders, there is a highly bureaucratic process to even get started with these suppliers: procedures, non-disclosure agreements, secure access to datasheets, export control, licensing terms, IP, etc. - Since there is no debug port, embedded development becomes a matter of having an expensive emulator and special developer licenses, again available only under NDA. - Although this does not prevent the source code from being published, without the datasheets, security guidelines, and a platform for performing tests, the outcome is questionable, with little practical value. You can disagree with this arguments, but just ignoring them to provide an "obvious" answer is a cheap tactic.

by rrego 10y ago

dublinben 10y ago

Not using hardware components that would require NDAs would be the obvious alternative.

sgift 10y ago
Obvious? As in "I didn't read the post, didn't read that there are only two suppliers for this kind of hardware and didn't read that both of them require this NDAs"-obvious? Quote for your convenience: So — why not combine the best of two worlds then, i.e. using secure hardware in an open-source design? There are a few problems with that: - There is an inverse relationship between making a chip open and achieving security certifications, such as Common Criteria. In order to achieve these higher levels of certifications, certain requirements are put on the final products and their use and available modes. - There are, in practice, only two major players providing secure silicon and none of their products/platforms are available on the open market for developers except in very large volumes. - Even for large volume orders, there is a highly bureaucratic process to even get started with these suppliers: procedures, non-disclosure agreements, secure access to datasheets, export control, licensing terms, IP, etc. - Since there is no debug port, embedded development becomes a matter of having an expensive emulator and special developer licenses, again available only under NDA. - Although this does not prevent the source code from being published, without the datasheets, security guidelines, and a platform for performing tests, the outcome is questionable, with little practical value. You can disagree with this arguments, but just ignoring them to provide an "obvious" answer is a cheap tactic.