Before someone goes into the typical "they don't get security" tirade we need to bring some reality to the table.
Lets say these devices all do the perfect thing and when first fired up generate their very own device signed public / private key pair. So what? How does this make them more secure if the device cannot provide the public to the end-user so they can match it to the one they got in the SSH or HTTPS connection before they establish that connection? The problem here is a chicken or the egg one, plain and simple. If they accept the security warnings and connect to the device, a man in the middle can simply tamper with the encrypted traffic so that when they view the device cert, it's the one they see in the connection. This I'm afraid is the elephant in the room when it comes to device connectivity over protocols utilizing public / private key cryptography.
Of course this problem can be solved, but I would propose that it wouldn't be cheap in many cases and doesn't really solve the problem. For devices with no display output the manufacturer could fire the device up on the product line and then obtain the public after it is generated. They could then print it out or save it to a USB drive and put it in the box with the device. Ultimately; however, the end user getting the device will have no idea what that paper or USB drive is and it will be promptly ignored anyway and browser or SSH security warnings will be accepted just as they are today.
The assumption for all of these products should be that they are untrustworthy until made trustworthy, even if they are generating their own unique key material. With that in mind they should be configured on isolated, trusted networks until which point they are secured. The only way to make them secure is if they can generate unique key material or accept organizational key material and then the connections are validated before establishing encrypted communication with the devices. Ideally this means having an organizational PKI program that can issue certificates to devices which are then validated against an organizational root CA or exporting the device generated public and importing it into hosts which will be used to connect with the device.
This I belive is the conversation we need to be having here.
Lets say these devices all do the perfect thing and when first fired up generate their very own device signed public / private key pair. So what? How does this make them more secure if the device cannot provide the public to the end-user so they can match it to the one they got in the SSH or HTTPS connection before they establish that connection? The problem here is a chicken or the egg one, plain and simple. If they accept the security warnings and connect to the device, a man in the middle can simply tamper with the encrypted traffic so that when they view the device cert, it's the one they see in the connection. This I'm afraid is the elephant in the room when it comes to device connectivity over protocols utilizing public / private key cryptography.
Of course this problem can be solved, but I would propose that it wouldn't be cheap in many cases and doesn't really solve the problem. For devices with no display output the manufacturer could fire the device up on the product line and then obtain the public after it is generated. They could then print it out or save it to a USB drive and put it in the box with the device. Ultimately; however, the end user getting the device will have no idea what that paper or USB drive is and it will be promptly ignored anyway and browser or SSH security warnings will be accepted just as they are today.
The assumption for all of these products should be that they are untrustworthy until made trustworthy, even if they are generating their own unique key material. With that in mind they should be configured on isolated, trusted networks until which point they are secured. The only way to make them secure is if they can generate unique key material or accept organizational key material and then the connections are validated before establishing encrypted communication with the devices. Ideally this means having an organizational PKI program that can issue certificates to devices which are then validated against an organizational root CA or exporting the device generated public and importing it into hosts which will be used to connect with the device.
This I belive is the conversation we need to be having here.