Secure Remote Access TechInfo
Micasaverde (Talk | contribs) (New page: We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer...) |
Revision as of 17:49, 9 April 2009
We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at forum.micasaverde.com for uncensored discussion about security concerns.
Vera listens on 2 network ports: port 80 is the normal web interface, and port 3451 is for a special control protocol. When Vera boots up, if the network settings have not been changed manually, Vera first checks if the IP address is an internal IP address (ie starts with 192.168, 10. or 172.x), and if there is a valid internet connection. Vera does this by pinging a couple common servers, such as google, youtube, and micasaverde, to confirm that it gets unique addresses for each domain name and that at least 2 of the 3 servers respond. If Vera has an internal IP address and a valid internet connection, all 5 ports on Vera go into 'switch' mode, meaning they're effective bridged, and there is no firewall. Thus Vera is open for access from another system on the same home network. If Vera has an external, or routable IP address, Vera goes into 'gateway' mode. The WAN and LAN ports are separated, a firewall is setup, a DHCP servers runs on the LAN ports providing addresses in the 192.168.81.x range, and Vera only accepts incoming connections on ports 80 and 3451 from the LAN ports. Thus, only PC's within the home should be able to access Vera, and nothing external, unless the homeowner changes the network settings or does a port forward on his firewall. Vera's built-in Wi-fi is enabled by default, which would allow users into the system. So we ship Vera with WPA2 encryption turned on, and a random wi-fi password consisting of 2 dictionary words plus a number, which is printed on the bottom of Vera.
Each Vera has 2 unique hardware keys which are stored in the nvram and assigned at the factory along with the serial number and the domain name for the remote access server that Vera will use. Only the remote access server for a particular Vera has a database with the serial numbers and hardware keys. When the user goes to the findvera.com tab on his setup page (ie from within the home) and activates the service, his username and an md5 hash of the password, along with the serial number and hardware key, are sent to the remote access server using https (ssl encryption). The remote access server validates that the serial number and hardware key match, and if so, reply with a port number that the Vera unit can use for remote access.
The Vera then uses ssh with a pre-defined ssh username and shared key to make a connection to the remote access server. The remote access server only accepts incoming ssh connections from that username with that shared key. And ssh is configured on the server so that when a connection comes in, rather than giving the ssh user a console (ie bash), it runs a script that requires the serial number and hardware key be sent in within 10 seconds. If they are, and they match, and the right port number was used, the ssh connection is authorized. If there is a mis-match, a log is filed with the incoming external IP address so we can add a block to this IP in the firewall in case this is a DOS or similar attack. The SSH connection includes a port forward of ports 80 and 3451 using the standard ssh port forward mechanism. This port forward does not allow 'gateway', that is, the ports are only accessible from within the remote access server.
NetworkMonitor runs on Vera and calls a php page on the remote access server using https, passing in the serial number and hardware key, which does a loop back test to ensure the ssh tunnel is active. If it's not, NetworkMonitor shuts it down and re-opens it.
When the user logs in through findvera.com, he is redirected to the remote access server that handles his username. The remote access server only accepts secure, https, connections. When the remote access server validates the username and password, then the php page on the control tab acts, effectively, as a gateway to the customer's Vera. It passes requests between the SSL connection and the ports 80/3451 that are forwarded from the ssh connection on Vera by looking up the ports that are associated with that username.
It should also be noted that we purposely never ask users for their home address so that if the remote access server ever were compromised, nobody would know the address of the Veras.
