I have a problem that it's bugging me:
I have some iBeacon devices (tags to be exact) and I want to create a custom new app supporting their functionality.
The problem is that every now and then the tags change their mac address (very frequently) as well as their UUID (frequently but not too frequently). The way I see it this feature has been implemented to protect users against tracking.
Now this can be hardware specific feature (I use the lasso tags) or be a standard functionality of the standard (iBeacon spec which I don't have).
Can someone please verify the intended functionality or at least give pointers to iBeacon official specification and/or other documents?
Regards
Recently, Apple made the iBeacon specification available on their iBeacon Developer pages: https://developer.apple.com/ibeacon/ (the "Download Artwork and Specification" link in the right-hand sidebar). You still need to accept the iBeacon License Agreement.
Some vendors use rotating UUIDs (and/or majors and minors) as a way to address security and privacy concerns, just like you said. It's not exactly what Apple intended for iBeacon (they mentioned on multiple occasions that you should plan around the possibility of beacons being spoofed, b/c iBeacon is not meant to be secure), but it's still compatible with the specification.
Most commonly, there's some known seed or secret key uploaded to the beacon during manufacturing or when enabling such security feature. Only authorized parties know the seed/key, and thus can either predict what's the UUID/major/minor of a beacon supposed to be at any given time, or decrypt it. In the end, UUID+major+minor is just 20 bytes of data broadcast by the beacon, and you can encrypt it just like any other data. (Well, actually, the problem with the iBeacon is that on the iOS side, you need to know the UUID of the beacon in order to scan for it, so at least the UUID—i.e., the first 16 bytes—need to be only pseudo-random, and can't be completely random.)
Personally, I would say this is one of the cases where the market validated the iBeacon idea/spec, and came up with a solution to a problem that Apple decided not to tackle. And I wouldn't blame them—they pretty much pioneered the beacon technology (sure, it was there before, but much less popular than it is today), and nobody at that time though about using iBeacon for tagging personal belongings.
When Google released Eddystone—i.e., an alternative beacon protocol—earlier this year, they announced at the very same time that encrypting the Eddystone identifiers will be part of the core spec:
At the same time, privacy and security are really important, so we built in a feature called Ephemeral Identifiers (EIDs) which change frequently, and allow only authorized clients to decode them. EIDs will enable you to securely do things like find your luggage once you get off the plane or find your lost keys. We’ll publish the technical specs of this design soon.
(source: http://googledevelopers.blogspot.com/2015/07/lighting-way-with-ble-beacons.html)
To me, this pretty much validates the idea of securing beacons, and rotating the UUIDs is just a clever market/community "hack" of the iBeacon spec to do just that.
Bluetooth LE beacons transmitting the iBeacon format, including those displaying the iBeacon certification logo, typically do not change their mac address. I base this statement on two years of experience testing these beacons from a wide variety of vendors. It is also unusual for an iBeacon to automatically change its ProximityUUID. These appear to be peculiarities that are specific to one vendor's implementation. The fact that these implementation details are unusual doesn't necessarily mean it isn't allowed -- it just means it is unusual.
Unfortunately, the iBeacon specification is proprietary and not publicly available from Apple. You need to enter a business relationship with Apple to be able to access the official documentation. That said, there is no shortage of information about iBeacons in the public domain obtained by folks who have reverse engineered the simple devices. In the absence of official public documentation, you simply have to do Google searches and use your judgement about the quality of the information you find.
Related
We already have a /.well-known/apple-developer-merchantid-domain-association.txt file under our domain which is used to verify our domain to Apple in relation to a checkout.com Apple Pay integration. Now we wish to have a completely independent Apple Pay integration (i.e. a different Apple merchant) using Adyen, operating under the same domain. This means we need to verify that too, by hosting a different /.well-known/apple-developer-merchantid-domain-association.txt... how can this be done while making sure the existing checkout.com integration doesn't lose its verification?
I was hoping maybe Apple includes some kind of header in the request signifying which merchant ID it's verifying, and based off of that we could dynamically change what we present? But I couldn't find anywhere detailing the exact process that goes on.
I've found lots of threads on the Apple developer forums about this, but none with a conclusive answer:
https://developer.apple.com/forums/thread/718160
https://developer.apple.com/forums/thread/118725
https://developer.apple.com/forums/thread/695538
Only the last one provides any kind of answer, which doesn't feel particularly robust as it seems like a big assumption that once it's verified Apple will never check again, an assumption that doesn't seem to be documented anywhere?
Are there any other possible solutions here?
I am extremely new to NFC as a technology and have a very basic question. I am investigating the use of NFC tags in the field of authentication. At a broader level imagine a PKI architecture. A private key resides on the NFC tag, and an app can access it for authentication/signing/validation etc.
I understand that smart cards are the de-facto standards for such things, but the cost of NFC tags is far far less. My question is what level of protection is offered by NFC tags for such a scenario or is NFC tag a good choice for such a design?
Can I somehow ensure that a tag is readable by only a certain device? As in, can another user just use his phone/NFC reader to read the key on the tag? What methods are available to protect/restrict access to the data residing on the NFC tag?
There is nothing inherent in an NFC tag that restricts access to read the data to one device. For the most part everyone can read, and everyone can write if the tag has not been made read-only. Some of the newer NTAG series of chips have password features allowing only software with the password to write the tag.
All NFC tags come with a unique manufacturer supplied id that is often uses in security implementations. It is very difficult, but not impossible to clone that ID. It is very easy to close the data on an NFC tag. There are a new set of "secure" tags being developed, but these often have a server-side component. One thing to note, is that while the data on the tag can be read by anyone, that says nothing about what value they actually get.
Many people encrypt the data and store the encrypted value on the NFC tag. The decryption key is then known by the software and can then read and interpret the tag's data. This requires custom software as its not a part of the current NDEF spec. This is really the same as SSL, where someone can sniff the network traffic but not know what the actual data is. In general we advise customers to make the NFC tags as "dumb" as possible and leverage NDEF for the broadest compatibility without custom software.
DISCLAIMER: I am the CEO of GoToTags, an NFC software and tag solutions provider.
NFC tags are basically a data store. They may provide restrictions for accessing data, but they remain a data store. If you implement a PKI with a NFC tag, you only store keys on the tag, no computation is done on tag.
On the other hand, PKI smart cards store the keys, but they also provide the computing resources for calculations done with the keys. Moreover, they are designed in a way keys never leave the card (on demand or by side-channel attacks). This way, you may expect key not to leak.
Because they offer different services, NFC and PKI card interfaces complexities are not the same at all.
Note some PKI smart cards do offer a contactless interface. This is not NFC tag interface, but rather PKCS#15 over ISO14443-4.
To learn CB, I've decided to browse the services on my iPhone. I'm finding a few, but except Battery and Time, the others are "Unknown". What is it?
Some services have defined UUIDs (such a battery and time) and these are listed on the Bluetooth Developer Portal. The defined services also have a set of defined characteristic IDs
BLE also allows developers to specify their own service and characteristic UUIDs - since the chance of collision for random UUIDs is infinitesimal, there is no requirement to register these, but organisations may choose to document them. Apple's notification center service defines some, for example, and many chipset/module vendors define services to make it simpler for developers to use their modules.
Looking at my Fitbit Flex I can see device information and battery services - these are well known, as well as two unknown services which, presumably, FitBit use to transfer activity and configuration information to and from the device. Short of trying to reverse-engineer their protocol there is no other information available on these services and characteristics.
Question: I have to come up with unique ID for each networked client, such that:
it (ID) should persist once client software is installed on target computer, and should continue to persist if software is re-installed on same computer and same OS installment,
it should not change if hardware configuration is modified in most ways (except changing the motherboard)
When hard drive with client software installed is cloned to another computer with identical hardware configuration (or, as similar as possible), client software should be aware of that change.
A little bit of explanation and some back-story:
This question is basically age old question that also touches the topic of software copy-protection, as some of the mechanisms used in that area are mentioned here. I should be clear at this point that I'm not looking for a copy-protection scheme. Please, read on. :)
I'm working on a client-server software that is supposed to work in a local network. One of the problems I have to solve is to identify each unique client in the network (not so much of a problem), so that I can apply certain attributes to every specific client, retain and enforce those attributes during the deployment lifetime of a specific client.
While I was looking for a solution, I was aware of the following:
Windows activation system uses some kind of heavy fingerprinting mechanism that is extremely sensitive to hardware modifications,
Disk imaging software copies along all Volume IDs (tied to each partition when formatted), and custom, uniquely generated IDs during installation process, during first run, or in any other way, that is strictly software in its nature, and stored in registry or on hard drive, so it's very easy to confuse two.
The obvious choice for this kind of problem would be to find out BIOS identifiers (not 100% sure if this is unique through identical motherboard models, though), as that's the only thing I can rely on that isn't duplicated, transferred by cloning, and that can't be changed (at least not by using some user-space program). Everything else fails as either being not reliable (MAC cloning, anyone?), or too demanding (in terms that it's too sensitive to configuration changes).
Sub-question that I'd like to ask is, am I doing it correctly, architecture-wise? Perhaps there is a better tool for the task that I have to accomplish...
Another approach I had in mind is something similar to a handshake mechanism, where a server maintains an internal lookup table of connected client IDs (which can be even completely software-based and non-unique at any given moment), and tells the client to come up with a different ID during handshake, if a duplicate ID is provided upon connection. That approach, unfortunately, doesn't play nicely with one of the requirements to tie attributes to specific client during lifetime.
It seems to me that you should construct the unique ID corresponding to your requirements. This ID can be constructed as a hash (like MD5, SHA1 or SHA512) from the information which is important for you (some information about software and hardware component).
You can make your solution more secure if you sign such hash with your private key and your software verify during the starting, that the key (signed hash value) is signed (only public key must be installed together with your software). One can expand such kind of solution with different online services, but corporate clients could find online services not so nice.
What you're looking for is the Windows WMI. You can get the motherboard ID (which is unique across the same type of motherboard) or many many other types of unique identifiers and come up with some clever seeded function to generate a UHID. Whoa did I just make up an acronym?
And if you're looking specifically for getting the Motherboard (BIOS) ID:
WMI class: Win32_BIOS
Namespace: \Root\Cimv2
Documentation: http://msdn.microsoft.com/en-us/library/aa394077(VS.85).aspx
Sample code: http://msdn.microsoft.com/en-us/library/aa390423%28VS.85%29.aspx
Edit: You didn't specify a language (and I assumed C++), but this can be done in Java (with a COM driver), and any .NET language, as well.
Many programs use the hostId in order to build a license code (like those based on FlexLM). Have a look at what Matlab does depending on the operative system:
http://www.mathworks.com/support/solutions/en/data/1-171PI/index.html
Also have a look at this question:
Getting a unique id from a unix-like system
Once I also saw some programs basing their licenses on the serial number of the hard drive, an maybe that is the less likely thing to change. Some would suggest to use the MAC of your ethernet card, but that can be reprogrammed.
MAC
DON'T RELY ON MAC! EVER. It is not permanent. The user can easily change it (under 30 seconds).
Volume ID
DON'T RELY ON Volume ID! EVER. It is not permanent. The user can easily change it. It also changes by simply formatting the drive.
WMI
WMI is a service. Can be easily disabled. Actually, I tried that and I find out that on many computers is disabled or broken (yes, quite often broken).
License server
Connection to a validation server may cause you also lots of troubles because:
* your customers may not always be connected to the Internet.
* your customers may connect with special settings (router/NAT/proxy/gateway) that they need to input into your program in order to let it connect to the validation server.
* they may be behind a firewall that will block all programs except a few (my case). In some cases the firewall may not be under their control (valid for MOST corporate users)!
* it is super easy to redirect your program to a local fake webserver that emulates your licensing server.
Hardware data
If you need strong protection you need to rely on hardware. Something that cannot be edited by the user. Something like CPU ID instruction available in the Intel/AMD CPUs and the serial number written into the drive's IDE interface.
The CPU ID and HDD ID are permanent. They will never change, not even after you format the computer and reinstall Windows.
It is doable. For example this library reads the hardware ID of a computer. There is a compiled demo and also sourcecode/DLL. Disclaimer: the link leads to a commercial product (19€/no royalties).
Update: this question is specifically about protecting (encipher / obfuscate) the content client side vs. doing it before transmission from the server. What are the pros / cons on going in an approach like itune's one - in which the files aren't ciphered / obfuscated before transmission.
As I added in my note in the original question, there are contracts in place that we need to comply to (as its the case for most services that implement drm). We push for drm free, and most content providers deals are on it, but that doesn't free us of obligations already in place.
I recently read some information regarding how itunes / fairplay approaches drm, and didn't expect to see the server actually serves the files without any protection.
The quote in this answer seems to capture the spirit of the issue.
The goal should simply be to "keep
honest people honest". If we go
further than this, only two things
happen:
We fight a battle we cannot win. Those who want to cheat will succeed.
We hurt the honest users of our product by making it more difficult to use.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
An extra bit of info: client environment is adobe air, multiple content types involved (music, video, flash apps, images).
So, is it reasonable to do like itune's fairplay and protect the media client side.
Note: I think unbreakable DRM is an unsolvable problem and as most looking for an answer to this, the need for it relates to it already being in a contract with content providers ... in the likes of reasonable best effort.
I think you might be missing something here. Users hate, hate, hate, HATE DRM. That's why no media company ever gets any traction when they try to use it.
The kicker here is that the contract says "reasonable best effort", and I haven't the faintest idea of what that will mean in a court of law.
What you want to do is make your client happy with the DRM you put on. I don't know what your client thinks DRM is, can do, costs in resources, or if your client is actually aware that DRM can be really annoying. You would have to answer that. You can try to educate the client, but that could be seen as trying to explain away substandard work.
If the client is not happy, the next fallback position is to get paid without litigation, and for that to happen, the contract has to be reasonably clear. Unfortunately, "reasonable best effort" isn't clear, so you might wind up in court. You may be able to renegotiate parts of the contract in the client's favor, or you may not.
If all else fails, you hope to win the court case.
I am not a lawyer, and this is not legal advice. I do see this as more of a question of expectations and possible legal interpretation than a technical question. I don't think we can help you here. You should consult with a lawyer who specializes in this sort of thing, and I don't even know what speciality to recommend. If you're in the US, call your local Bar Association and ask for a referral.
I don't see any impact on the honest users in here, files would be tied to the user - regardless if this happens client or server side. This does gives another chance to those in 1.
Files being tied to the user requires some method of verifying that there is a user. What happens when your verification server goes down (or is discontinued, as Wal-Mart did)?
There is no level of DRM that doesn't affect at least some "honest users".
Data can be copied
As long as client hardware, standalone, can not distinguish between a "good" and a "bad" copy, you will end up limiting all general copies, and copy mechanisms. Most DRM companies deal with this fact by a telling me how much this technology sets me free. Almost as if people would start to believe when they hear the same thing often enough...
Code can't be protected on the client. Protecting code on the server is a largely solved problem. Protecting code on the client isn't. All current approaches come with stingy restrictions.
Impact works in subtle ways. At the very least, you have the additional cost of implementing client-side-DRM (and all follow-up cost, including the horde of "DMCA"-shouting lawyer gorillas) It is hard to prove that you will offset this cost with the increased revenue.
It's not just about code and crypto. Once you implement client-side DRM, you unleash a chain of events in Marketing, Public Relations and Legal. A long as they don't stop to alienate users, you don't need to bother.
To answer the question "is it reasonable", you have to be clear when you use the word "protect" what you're trying to protect against...
For example, are you trying to:
authorized users from using their downloaded content via your app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
authorized users from using their downloaded content via any app under certain circumstances (e.g. rental period expiry, copied to a different computer, etc)?
unauthorized users from using content received from authorized users via your app?
unauthorized users from using content received from authorized users via any app?
known users from accessing unpurchased/unauthorized content from the media library on your server via your app?
known users from accessing unpurchased/unauthorized content from the media library on your server via any app?
unknown users from accessing the media library on your server via your app?
unknown users from accessing the media library on your server via any app?
etc...
"Any app" in the above can include things like:
other player programs designed to interoperate/cooperate with your site (e.g. for flickr)
programs designed to convert content to other formats, possibly non-DRM formats
hostile programs designed to
From the article you linked, you can start to see some of the possible limitations of applying the DRM client-side...
The third, originally used in PyMusique, a Linux client for the iTunes Store, pretends to be iTunes. It requested songs from Apple's servers and then downloaded the purchased songs without locking them, as iTunes would.
The fourth, used in FairKeys, also pretends to be iTunes; it requests a user's keys from Apple's servers and then uses these keys to unlock existing purchased songs.
Neither of these approaches required breaking the DRM being applied, or even hacking any of the products involved; they could be done simply by passively observing the protocols involved, and then imitating them.
So the question becomes: are you trying to protect against these kinds of attack?
If yes, then client-applied DRM is not reasonable.
If no (for example, you're only concerned about people using your app, like Apple/iTunes does), then it might be.
(repeat this process for every situation you can think of. If the adig nswer is always either "client-applied DRM will protect me" or "I'm not trying to protect against this situation", then using client-applied DRM is resonable.)
Note that for the last four of my examples, while DRM would protect against those situations as a side-effect, it's not the best place to enforce those restrictions. Those kinds of restrictions are best applied on the server in the login/authorization process.
If the server serves the content without protection, it's because the encryption is per-client.
That being said, wireshark will foil your best-laid plans.
Encryption alone is usually just as good as sending a boolean telling you if you're allowed to use the content, since the bypass is usually just changing the input/output to one encryption API call...
You want to use heavy binary obfuscation on the client side if you want the protection to literally hold for more than 5 minutes. Using decryption on the client side, make sure the data cannot be replayed and that the only way to bypass the system is to reverse engineer the entire binary protection scheme. Properly done, this will stop all the kids.
On another note, if this is a product to be run on an operating system, don't use processor specific or operating system specific anomalies such as the Windows PEB/TEB/syscalls and processor bugs, those will only make the program even less portable than DRM already is.
Oh and to answer the question title: No. It's a waste of time and money, and will make your product not work on my hardened Linux system.