Please do not take my lack of detail and an encyclopedic response as anything but my wanting to be immediately responsive to a university undertaking. All I can say, and in wanting to keep our system secure, is that your assumptions about message content and timing are well thought out, but the reality of our messages and the underlying code, prevents such conclusions to be made. Getting into more detail might be a security risk. That being said, we understand any group with enough motivation and resources could corrupt any system.

As a former Professor I would like to support the students and the faculty in their enterprise. But as I have found out in the 12 years I have been in industry after academia, at least in my endeavors, industry knowledge and experience is orders of magnitude deeper than that of nearly all graduate seminar participants. Our tech team has built some very successful and secure platforms used in the world today including (just to name two) the Instinet trading platform and much of the original Medscape system).

We deal with thousands of lives and emergency interdictions on a daily basis. Now, while no one can ever anticipate every potential attack or security threat, we have taken every measure we can think of, not all of which I would or could prudently discuss on a forum like this. And we are constantly on the lookout for new threats and counter measures. Our systems has undergone at least three independent reviews and will continue to undergo such reviews.

I cannot go into, nor should I go into the details of our security, the security vetting by security companies that our system has undergone, nor can I go into the detail of each and every communication, its timing, content, and level of privacy protection in this forum (nor should I for security reasons).

All of the issues that you have pointed to and a host of others that you have not listed have been addressed by the QuietCare technical team.

Student exercises are just that, good thought experiment that exercise their minds, we have to deal with the well being of our clients, the communication with their family members and a host of professional caregivers and our business depends on it. We know that we do not know everything, therefore we always welcome constructive feedback and criticism and thank you and the students for their ideas.

Please feel free to contact me directly.

George Boyajian george@quietcaresystems.com

But things changed recently with the embedded system evolution and IP based service expansion. The family system starts to take in-bound connection to handle requests. Typical application for such in-bound connection can be found in P2P games, VIOP and IP video surveillance.

Take IP video surveillance as example, a web server running in an embedded device and server the in-coming request for real time video, snapshot, recorded images or administration tasks. Service is supposed to be more vulnerable than non service application because it will open more ports and take in information from outside, which can be malicious.

An embedded device running open service such as ftp, web deployed in family environment can impose great security threat on regular family users. The reasons can be briefly summed as following:

1. Family system is the least protected end point in the WWWW world. No professional system admin, no commercial grade firewall, no password and security policy.
2. Family users are regulars users without much knowledge how to protect their network, and how to detect the attack.
3. Most services running in embedded system are implemented loosely without security in the first place
4. For an embedded system, the end to end connection channel protection is impossible. The standard SSL just does not work for embedded system, the reason for that is no one won’t pay and update certificate after the device is shipped.

No matter how an IP camera brag its security feature, it can be very easily to be tampered if somebody really want to, because if there is no protection in the whole transportation channel, the device is regarded no protection. Same for other embedded device with open services running.

However, the security flaw for embedded is not really this significant as it sounds. The reason is the limited ability for an embedded system, because a tampered embedded system won’t be harmful as a desktop system.

At some point the electronics are actuating a mechanical device to arm the firearm. This device can be actuated by wiring around the ‘brains’ and directly to the actuator. Alternatively, the actuator can be mechanically jimmied.

These devices may prevent grabs, but are useless if the criminal or inquisitive child has more than a few minutes to play with the firearm.

I’m suggesting we build a good botnet by buying the machines, not steal one through nefarious means.

–Colin

http://www.schneier.com/blog/archives/2006/12/defeating_rfids.html