Simply put, how does Eddystone-EID work and what are the main use cases?
Standard beacons transmit a unique identifier so apps can tell when they are in a particular place. But because this identifier is in clear text, any app can read this identifier, and use the transmission to know where it is. An unauthorized third party app can make use of standard beacons that the app's authors did not deploy.
Eddystone-EID encrypts it's identifier and rotates it periodically to prevent others from making use of the beacon identifier. Authorized apps can use a "trusted resolver" to get a stable identifier from the rotating encrypted one in the transmission. A server call is needed to convert the 8-byte AES encrypted identifier to a stable one.
Google's Proximity Beacon API provides this conversion. It is theoretically possible to build an independent trusted resolver apart from Google (I have done so for testing purposes), but otherwise you must register your EID beacons with Google and use their web services to resolve their identifiers.
An example ephemeral identifier looks like this:
0a194f562c97d2ea.
Here's a write up I did on the topic: http://altbeacon.github.io/android-beacon-library/eddystone-eid.html
Here's an explanation I found on a developers.google.com page here.
What happens when a client sights an Eddystone-EID beacon?
When a client device sights an Eddystone-EID beacon as a result of a Nearby1 subscription, the current EID is sent to the Google Proximity Beacon API2 along with the API key of the calling app. The Google Proximity Beacon API establishes whether the supplied API key is authorized to fetch attachments that have been associated with the beacon. If resolution is allowed, the attachments are served back as Nearby message objects in the normal way. Otherwise, Google Proximity Beacon API returns an empty value, as it would if the beacon had not been registered.
1 - The beacon scanning component of the Google beacon platform
2 - The Proximity Beacon API is a cloud service that allows you to manage data associated with your BLE beacons using a REST interface.
Here's another paragraph which I found critical to understand how the technology works.
Eddystone-EID is designed to give developers control over which clients can make use of their beacon signals. The beacon identifier changes pseudo-randomly in such a way that it can only be resolved to stable information by a resolution service that shares an encryption key with the beacon. Without access to the resolution service, the beacon identifier is of little use.
Eddystone-EID is appropriate for cases where beacon deployers wish to:
Prevent other parties from using their beacons.
Preserve user privacy in scenarios involving wearables or other equipment carried by the user.
Lease their beacon network to other parties in a way that allows a provable 'off switch' for access.
Provide a strong signal that a user is at a particular place, that is not easily spoofed.
Related
I tried to configure a bonding pincode on my Movesense 2.0.0 sensor and I was expecting being asked for it when trying to connect to the sensor with MDS or apps like nRF Connect.
But what I got looks identical to Just Works mode, and the bonding PIN is being asked only if I try to pair the device through system's Bluetooth settings. Does it happen because in the first case there's only connection and no pairing? What are the pros/use cases for having the sensor paired at system-level?
I'm looking for a way to prevent unauthorized access (connections, API requests) to sensors from devices not knowing a secret access code (like a PIN). Do BLE/Movesense provide such a mechanism?
Neither Bluetooth nor Movesense offer a way to securely "log in with a secret password". The passkey bonding mechanism that is present in Bluetooth, is only designed with the purpose of avoiding man in the middle attacks, and the passkey must be random everytime since the protocol reveals the key after each attempt. A static passkey which some people use is not allowed per the specification. It might keep away your grandmother from accessing the device, but is not secure at all at a protocol level.
If you bond the device at a system level, the further communication will be secure (encrypted and authenticated) and will for example prevent spoofing attacks. It will also result in quicker device connection setup since GATT caching can be used.
You are not saying what "system" you are using so this is just a general answer.
I know iBeacon only broadcasts UUID signal. What I'm reading about Proximity Beacon API is confusing. We must register:
Advertised ID (required)
Status
Stability
Latitude and longitude
Indoor floor level
Google Places API Place ID.
Text description
Arbitrary properties as key/value pairs
Does Eddystone broadcast all the information above, as shown on this image?
Beacons broadcast very little information themselves — typically only a Proximity UUID + major + minor (for iBeacons) or a BeaconID + transmission power (for Eddystone UID beacons).
The Proximity Beacon API is a service that allows you to "register" a beacon along with additional information for it. Some of this information, such as:
PlaceID
Building level
Stability
Lat/Lng
Description
Properties
are entirely optional are only for the registering beacon owner's own uses. You can choose to specify exactly where a beacon is with a lat/lng and a PlaceID, or you can skip these.
The Proximity Beacon API also lets you associate little pieces of data called "attachments" to your beacon. These are things that people can see when they run into your beacons in the wild. The content and format of these are entirely up to you.
So, if you want to register a beacon with the PB API, the only thing you MUST specify is the advertisementId.
For an Eddystone beacon, this will be 16 bytes (The BeaconID from the UID Frame) whereas for iBeacons, this will be 20 bytes (16 byte iBeacon Proximity UUID + 2 byte major + 2 byte minor).
Note that as per my answer to another question, what you upload to the register function for the beacon is a base64 encoded string representing the underlying BINARY data. So, get a Buffer or byte array representing the advertisement ID and then base64 encode that.
As you noted, the beacon itself only broadcasts its identifier—i.e., UUID + Major + Minor for iBeacon, and Namespace + Instance for Eddystone.
These additional fields that you register with Google's Proximity API are stored entirely on their server, and not broadcast by the beacon.
When you detect a beacon, you can read its identifier from the advertising packet, and use it to retrieve the additional data from Proximity API.
Imagine you have a beacon with identifier X. You upload the beacon's data to Proximity API, e.g., Advertised ID = X, description = "My beacon". Later, when your app detects that beacon, it can go to the Proximity API and say "give me data for beacon X", and that's how you gain access to the extra information, e.g., the "My beacon" description.
The image you've linked to is from a Proximity API tutorial I remember seeing on the Internet, and it's just a simplification, because strictly speaking, the beacon doesn't broadcast all this information, only the identifier. But this identifier is enough to fetch the extra data from Proximity API (providing you have Internet connection), so one can think about Proximity API as something that extends what you know about the beacon, and I think that's the reason why the image shows it this way.
It is possible to know others NFC TAG ID when we used to the APK & TAG each phones.
For example,
Phone A and B try to tag. Then Phone A can know Phone B's NFC TAG ID (4 Bytes - HEX).
But I wanna know how to know my NFC TAG ID on my phone. Not used other phones.
If you know any other information, please give me your advice on that.
A phone does not necessarily have a fixed anti-collision identifier ("NFC Tag ID", as you call it). For instance, it could have an anti-collision identifier, that is randomly allocated on every activation (e.g. external HF field is turned on, phone is turned on, etc.) It could also have one or even multiple immutable anti-collision identifiers (e.g. from one or more secure elements).
This depends on several factors:
Is a secure element attached to the NFC controller in that phone?
Is the NFC controller configured to expose an attached secure element to the outside world?
Is the phone in card emulation mode or in passive peer-to-peer mode (or in a combined anti-collision phase for both modes)?
Does the NFC controller expose exactly one card-emulating entity (e.g. a secure element or the host controller) directly to the outside world or does it combine one or more emulating entities using NFCEE routing?
Etc.
As you mention "APK" I'm guessing that you refer to the Android platfrom (though you refused to answer my question on that). On newer Android devices (particularly those that support Host-based Card Emulation) and on Android devices that do not use card emulation at all, the anti-collision identifier (UID) visible to the outside world is typically not static and changes either on every activation or on every reboot of the device (some exceptions seem to exist). Particularly, with NFC peer-to-peer mode, the standard mandates the use of a per-session random identifier. Thus, the UID would not be of much use in those typical cases.
In general, Android does not provide any API to retrive the currently used anti-collision identifier from within the device. Usually, the random identifier is created within the NFC controller, so the Android system would not even know about it.
With regard to immutable IDs of secure element chips, vanilla Android does not contain public API to access secure elements, so the same applies to any identifing information of such secure elements.
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.
Could someone suggest a tutorial/sample on how an Iphone application can send data to a remote server using Carrier Data Network only? In other words is there a way an application can programmatically force to enable Carrier Data Network communication, use it to send its request to the remote server and switch it back to user specific communication settings.
I am taking this approach because my application needs to send user's personal info to my server and sending it over public WiFi does not sound right. Please let me know if there is better approach to it....
Thanks
Since no one's writing a full answer ...
I don't know if it's possible to detect CDN vs Wi-Fi, although at some level it must be because the App Store is capable of determining such to prevent large CDN downloads. Of course, the App Store app has access to the private APIs; this functionality may not be exposed publicly. (I don't know if that is the case or not, but be sure you do not use private APIs for your app; the store won't accept it.)
That said, think about the use case of your app, and the marketplace. The iPhone OS and the iPhone App Store are more than just the phones themselves -- they're the iPhone and iPod Touch devices. iPod Touches do not have a CDN; they're Wi-Fi only for connectivity.
As Marc W said in a comment, not all Wi-Fi is public, not all public Wi-Fi is free, and you will likely upset a significant portion of your audience -- people (presumably and hopefully) giving you money.
A better solution would be to use SSL to provide encryption of the private data during transport. This is widely available, works over CDN or Wi-Fi, and provides all the security you should need.
If you look at the Apple Reachability example code, you can test for how you would access a host - however I agree with the other posters that you should consider encrypting your data and let your user's determine how they want to connect to the Internet, and not force one form of connection.
-t