[dmitrygr]

This reads more like an excuse then a reason. Nothing of what he says is a reason that prevents them from being more open.

All that he says is summarized in "it was too hard to think of a solution, so we didn't do it."

[rrego]

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]

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

[sgift]

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.

[skybrian]

I'm not sure what distinction you're making? "Too hard" is often a valid reason for not doing something.

[dmitrygr]

Yes, unless you refuse to admit it and instead claim that security is improved by obscurity you chose to engage in.

[jolux]

But this isn't completely security by obscurity, it's security granted by hardware that is built for secure purposes for which it is difficult to provide a software platform.