I do have a question about the best practice for AWS IoT devices, should I create a certificate per device or should I use one certificate for multiple devices or per device type?
I'm trying to find the best practice but I still not getting any information about it.
Each device should have its own unique certificate. Certificates should be used as a form of unique identity for a device.
While you can setup AWS IoT policy based on the client id, that should not be used to uniquely identify a device. Since the client id can potentially be changed through reversed engineering and changed to be whatever device it wanted to be.
While adding the unique certificate does not prevent tampering with the client id, it does give you the ability to block that single device from connecting.
You should create one certificate for each device and attach a policy to that certificate. One policy can be attached to different certificates.
Related
I've created an app that uses the USB API to open a new tab when the USB device is connected.
But now I want to improve it a bit. Before, when I use USB API I must define its vendorID and productID in the manifest. It means my app only use exactly one USB device.
Now I want any USB to interact with my app. Anybody can give me an idea to do it?
I do believe it's impossible for security reasons. You can specify more than one PID/VID pair, but you cannot ask for arbitrary ones.
The stated reason for this is to prevent apps from fingerprinting hardware by enumerating all connected USB devices, which has a good chance to be a unique set.
I was just installing Ubuntu and noticed it was downloading updates from ca.archive.ubuntu.com. How did it know I was in Canada? As far as I'm aware an IP packet carries no information regarding physical (geographcial location) and there is no stipulation in the Ethernet standard saying anything about information regarding location.
So how do things such as geolocation work? For example this website tells you which country your IP address belongs to. Is it just a matter of looking up an IP address in a table? If so where does the data come from, it's not as if people actively signup to have their IP address associated with the building address?
how does IP address geolocation work, does it just lookup the IP from a table?
Yes, that's exactly how it works.
IP geolocation is nothing more complicated than a database lookup. IP addresses are assigned by IANA to regional governing entities who then assign (sell) them to ISPs, governments and corporations (IBM for example has a dedicated block of IP addresses for themselves because they got into the internet game very early on).
Based on this fact we can sort of figure out where an IP address is located. IANA themselves publish the block level allocations on their site: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml which is rendered beautifully in this XKCD comic: http://xkcd.com/195/.
As for the more detailed info like which city that IP address comes from, to get that information requires more data gathering. Some ISPs may tell you their assignment schemes, most dont. So most databases like whatismyipaddress.com painfully build theirs up by surveys (simply asking people where they are or via smartphone apps tapping into GPS), looking up whois databases (which may or may not lie) and careful guessing.
Yes, your IP carries a geolocation as well. I'm not sure that's the best way to describe it, as it doesn't really carry the information (I don't think?). This link gives a pretty good idea of the kind of details they can get from your ISP though:
http://whatismyipaddress.com/geolocation-accuracy
Of course all of that revealing information can be partially negated by using a proxy.
My company is currently developping an embedded device running uClinux.
Those devices are supposed to be deployed in both un-managed and managed networks.
We are looking for the best strategy to assign static IP addresses (and subnet masks) to those devices (from a Windows computer on the network) when no DHCP (or BOOTP) server is available and save those values to a configuration file in the device.
This strategy shall avoid the usage of ssh, telnet or any similar interface.
The device would be set with a factory default IP address and netmask (i.e. something like 192.168.1.1). Ideally, the strategy woudl also enable us to activate or de-activate DHCP support in those devices. The MAC addresses of the devices would be known information available that could be used in any kind of tool running on a Windows computer.
Does anyone know if any standard way of doing such a thing does exists? Any recommendation ensuring possible future portability on other platform than uClinux is welcome. A combination of standard Busybox tools or uCLinux available tools would be ideal.
Thanks in advance,
Francois
I think the best strategy is to use Zeroconf, which in embedded linux can be achieved with Avahi. The idea is that the device automatically assigns an IPv4 or IPv6 address to itself and resolves conflicts of addresses if necessary.
Devices can be discovered on the network and you can access them even if you have services running on the board. The best strategy is to have an IP alias on the network card with the zeroconf address and on the main interface you put the address you prefer
How to identify user's device on authentication -- such that second factor auth (such as SMS) can be enforced if user is logging in from an unknown device? I've seen google and facebook has this feature, and they're not using a simple IP check -- if I have two devices on the same network, it can still detect if I tried logging in from an unknown device.
Especially on websites -- as far as I know we can only get user's IP, and other information on HTTP headers, but how do we identify the user's device securely?
You could use cookies - if the user doesn't have the appropriate cookie, then require a successful two factor authentication?
You could also consider browser fingerprinting in combination with IP address / geo-ip information for a more heuristic approach, though that would be a lot more complex to implement and likely more fragile.
My bank website has a security feature that let me register the machines that are allowed to make banking transactions. If someone steals my password, he won't be able to transfer my money from his computer. Only my personal computers are allowed to make transcations from my account. So...
What are the approaches to restrict the access to a group of machines in a web system?
In other words, how to identify the computer who made the http request in the web server?
Why not using a clients certificate inside the certificate store of an authorized host or inside a cryptographic token such as smartcard that can be plugged into any desired computer?
Update: You should take into account that uniquely identifying a computer means obtaining something that is at a relative low level, unaccessable to code embeded in an html page (Javascript, not signed applet or activeX), unless you install something in the desired computer (or executing something signed such as an applet or activeX).
One thing that is unique per computer is the MAC address of the Ethernet card, that is almost ubiquitous on every rather modern (and not so modern) computer. However that couldn't be secure enough since many cards allow changing its MAC address.
Pentium III used to have an unique serial number inside CPU, that could fit perfect for your use. The downside is that no newer CPUs come with such a thing due to privacy concerns from most users.
You could also combine many elements of the computer such as CPU id (model, speed, etc.), motherboard model, hard disk space, memory installed and so on. I think Windows XP used to gather such type of information to feed a hash to uniquely identify a computer for activation purposes.
Update 2: Hard disks also come with serial numbers that can be retrieved by software. Here is an example of how to get it for activation purposes (your case). However it will work if sb takes the HD to another computer. Nonetheless you can still combine it with more unique data from computer (such as MAC address as I said before). I would also add a unique key generated for a user and kept in a database of your own would (that could be retrieved online from a server) along with the rest to feed a hash function that identifies the system.
Did you actually install something?
Over and above what Mark Brittingham mentions about IP addresses, I suppose some kind of hash code that is known only to your bank's computer and your computer(s) would work, provided you installed something. However, if you don't have a very strong password to begin with, what would stop someone from "registering" their computer to steal money from you?
I would guess your bank was doing it by using a trusted applet - my bank used to have a similar approach (honestly I thought it was a bit of a hassle - now they're using a calculator-like code generator instead). The trusted applet has access to your file system, so it can write some sort of identifier to a file on your system and retrieve this later.
A tutorial on using trusted applets.
I'm thinking about using Gears to store locally a hash-something to flag that the computer is registered.
If you are looking for the IP address of the computer that makes an account-creation request, you can easily pull that from the Request. In ASP.NET, you'd use:
string IPAddress = Request.UserHostAddress;
You could then store that with the account record and only accept logins for that account from that IP address. The problem, of course, is that this will not work for a public site at all. Most people come through an ISP that assigns IP addresses dynamically. Even with an always-on internet connection, the ISP will occasionally drop and re-open the connection, resulting in a change of IP address.
Anyway, is this what you are looking for?
Update: if you are looking to register a specific computer, have you considered using cookies? The drawback, of course, is that someone may clear their cookies and thus "unregister" their computer. The problem is, the web only has so much access to your computer (not much) so there is no fool-proof way to "register" a computer. Even if you install an ActiveX control, they could uninstall or delete it (although this is more persistent than a cookie). In the end, you'll always have to provide the end-user with some method for re-registering. And, if you do that, then you might as well have then log in anyway.