As the person who kicked off this discussion I’d like to say two things first:
@zachary - I really appreciate your positive attitude to the discussion, on the TI forums I didn’t get such a strong feeling of directness and openness.
@zach - thanks for the background information, glad to see there’s someone with a clear story here about the development of the CC3000, rather than the rather confused talk on the TI forum about patents (which no one can actually point to, not even to the relevant patent applications) and vague discussions of proprietary processes.
I think security through obscurity is no real security so why do TI even maintain a pretence, they should be open and just say if you don’t use AES then you trade security for convenience - and that for some people this will be an acceptable trade and for some not.
I think providing an AES key to the end user is a tricky issue, we can throw around ideas here but all will, I suspect, have issues similar to the AES vs non-AES approach, i.e. convenience vs security.
E.g. if stickers were being used then one would try to get someone into the supply chain for such devices, if this person saw that a shipment was going to be made to an interesting target, e.g. a big bank, then they would note down the numbers before the delivery.
One could then use tamper proof stickers and other approaches, all again with pluses and negatives.
I appreciate what people are saying about momentary insecurity and that many end users will not be big banks but individuals who may accept the convenience/security tradeoff.
However I think device manufacturers cannot limit who uses their end products.
I think CC3000 enabled devices will be hard to police, and will be a big headache to corporations. E.g. as I posted on the TI forum I think the CC3000 is a bigger risk to a corporation than most other security issues, e.g. end users copying data onto USB sticks.
I’m talking here about security issues resulting from employee carelessness rather than malicious insider attack.
One can say that one’s policy is no copying data onto USB keys but the risk is still low if a non-malicious party disobeys this rule (e.g. so they can work on something at home). It’s hard for an external party to look out for such occurrences, however the same is not true if an external parties is looking out for the installation of a CC3000 device on a given network.
Anyone who’s worked in a corporate environment knows people routinely disobey the security rules, e.g. write their password on a postit etc.
If CC3000 enabled devices become popular then it’s inevitable that someday one of the employees will bring in some fun device they got and connect it to the network even if the rules prohibit it, simply because they fail to appreciate the issues involved in what they’re doing.
I think it’s not just end users that will fail to understand the issues, I think many manufactures will too, e.g. not even thinking about whether AES should be used, just going with the easy option, or not appreciating the issues involved in secure AES key delivery or using the same AES key with all devices.
Basically I think the nature of the CC3000 (rather than some fixable flaw) means that it will introduce unanticipated security issues for end users for whom momentary insecurity, whether they know it or not, is not acceptable.
BDub - transferring credentials via USB sounds like a good idea to me, it means no third party can watch the traffic or impersonate the device (e.g. with CC3000 someone could listen for credentials and pretend to be the relevant device). All smartphones have USB capabilities - but I guess the CC3000 approach looks nicer as it doesn’t require the end user to have the necessary cable with them or having to provide a cable with the device along with the necessary adapters (for lightening or the old style 30-pin connector for Apple devices, mini and micro USB for Android etc. devices).
PS sorry BDub that I couldn’t put the at-symbol in front of your name above - apparently new users can only use the at-symbol twice in a given message