Customize UUID #9

Closed
mighani opened this Issue Nov 10, 2013 · 76 comments

Projects

None yet
@mighani
mighani commented Nov 10, 2013

Will it be possible to customize the UUID of the iBeacons?
How else could i e.g. distinguish all my beacons (from my company) belonging to a specific store belonging to a brand? As the UUID is some sort of namespace.

Thanks,
masiar

I was reading through some of the api docs (apples/ maybe it was also estimotes) and there is a way to write to them so I can only assume you can programmatically change the UUID.

mighani commented Nov 10, 2013

You can start an iBeacon advertising its presence by providing an uuid to the api call. The uuid itself can be generated through apples uuidgen. But this is ios7 sdk. I didnt find a way to do it with the estimote sdk. There is only this string identifier which is for internal use. I assume ithe uuid in estimote can not be changed, but i hope this isnt true. At least i dont see any obvious reason to hardcode it into some unreachable property.

I read elsewhere estimote are going to update their apps on the app store to allow writing new UUIDS I just took a look at the SDK headers and they allow writing the Major and Minor numbers so its a matter of time or hacking to find out how to update the UUID, I'll be writing an app soon to attempt all this once I finally get the beacons sigh.

Contributor

Hi all!

It is not possible to change UUID for Estimote beacons. We are not planning give this option any time soon. All deviceas are going to be managed based on unique major and minor combination.

Might I ask why your not allowing this?

@mikey0000: due to security reasons. As you know beacons could be updated over the air and there is a new version on beacon operating system being developed that will encapsulate UUIDs into a secure ID you could get using our SDK and have a full control over that.

At this moment changing UUID and/or minor/major might lead to vulnerability, so we don't expect it make sense to play with that.

May I know why you wanted to change it?

Yeah that pretty much solves my issue of people being able to mess with the beacon id's. Basically I want to be assured that the beacons for different locations can't be pirated by end users for monetary gain or in this case our rewards system. if all it requires is to know the major and minor number then someone can easily emulate the beacon and profit off our system. alternatively we can also bound them by their gps location too. My issue is the same as what you've basically said, security.

Ok, then don't worry about that. We have already solved it and soon have new features to announce ; )

Legend!

@jimiasty So what you are saying is that you are providing us a fourth value used to distinguish my beacons from others. Unfortunately, this change locks me into your SDK. By not giving me the full power of iBeacon while using the APIs provided by Apple, I'm not going to choose to use your beacons. I'm going to guess that I won't be the only one who doesn't want to get locked into a manufacturer's SDK for what is a public API from Apple. Just giving you my feedback.

Could you also expand on why you think giving us the power to change the UUID is a security risk? It can't be any more of a risk than all of your beacons using the exact same UUID.

mighani commented Nov 15, 2013

Would it not make sense to rather secure the process of updating over the air instead of cutting off the possibility to set a custom uuid?

@rickdahl: thanks for your feedback - we appreciate it a lot.

As we discussed we are focused on security and privacy. Our beacons implement secure mode where UUID can be encrypted and can be decrypted using our SDK. The feature is not available yet, but will be included into next software update for beacons.
Due to security reasons we don't plan to allow users to change the UUID. We recommend using our SDK to identify location and zones.

This issue cannot be done differently and it does not matter which vendor you choose - it will always require to select one unless industry standards are introduced (will take some time).

We are highly motivated to provide developers with easy, powerful and flexible solutions that respect privacy and are secure.

@mighani: This is already on our roadmap. The future beacon OS update will protect beacons to be manipulated from other people than the owner.

ygini commented Nov 20, 2013

Hi folks,

I'm Yoann, the guys behind https://github.com/ygini/EstimoteEditor.

I've wait your device for a while now and I'm really happy to use them as a prototyping device.

Hoever, and like I've said to Ola before, your tool won't be used on any deployment under my supervision if you don't improve two things :

  • settings' security
  • UUID modification

To be really clear, you don't have to lock the UUID. It's something under the control of the end user for one simple reason, it's a context aware information.

With read-only UUID, your beacon can't be used with others beacon and this is a no-go signal for many people. No scalability, no update proof, deployment link to only one hardware supplier. Definitively a no go.

Estimote is really interesting because it simple and it's cheap. But it not gonna be deployed on field if it become a restrictive solution.

UUID is used as primary region identifier. It can be used in many way by developers and set a read only value here reduce the level of possibilities. Simple example, each retail group can choose their own UUID, use major version for the store identifier and the minor for product identifier. Three custom settings is always better than two.

An other thing, your SDK won't be used for final deployment, don't hope any thing on that. You SDK will be used by implementer to configure the beacon with correct settings. But on consumer product, it won't be your SDK used, but the native SDK on the platform.

The reason is simple, software are generic, hardware delivery is specific.

Imagine a simple situation, you're a software developer working for a big retail brand deployed worldwide. The mother ship decide to develop advertising solution based on iBeacon and develop an application with this goal. To make this application, they will never chose to use a SDK specific to one small implementer with no guarantee over the time.

Rational choice ask to use only standard based solution and avoid anything custom to rationalise software code and allow simple hardware provider switch based on local law, product availability, public market, etc.

Be really sure about what you're gonna do with this. Estimote beacon have a good buzz at this time, you're a interesting actor on this market but you won't lead the run if you make the mistake to limit software developer to your vision of the product. You must at least do what the standard do. You can do more, but not less if you wan't to keep an active community.

I really hope you will go back on the right track, I will be sad to never use your product on a real project.

+1

On Wed, Nov 20, 2013 at 7:54 AM, Yoann Gini notifications@github.comwrote:

Hi folks,

I'm Yoann, the guys behind https://github.com/ygini/EstimoteEditor.

I've wait your device for a while now and I'm really happy to use them as
a prototyping device.

Hoever, and like I've said to Ola before, your tool won't be used on any
deployment under my supervision if you don't improve two things :

  • settings' security
  • UUID modification

To be really clear, you don't have to lock the UUID. It's something under
the control of the end user for one simple reason, it's a context aware
information.

With read-only UUID, your beacon can't be used with others beacon and this
is a no-go signal for many people. No scalability, no update proof,
deployment link to only one hardware supplier. Definitively a no go.

Estimote is really interesting because it simple and it's cheap. But it
not gonna be deployed on field if it become a restrictive solution.

UUID is used as primary region identifier. It can be used in many way by
developers and set a read only value here reduce the level of
possibilities. Simple example, each retail group can choose their own UUID,
use major version for the store identifier and the minor for product
identifier. Three custom settings is always better than two.

An other thing, your SDK won't be used for final deployment, don't hope
any thing on that. You SDK will be used by implementer to configure the
beacon with correct settings. But on consumer product, it won't be your SDK
used, but the native SDK on the platform.

The reason is simple, software are generic, hardware delivery is specific.

Imagine a simple situation, you're a software developer working for a big
retail brand deployed worldwide. The mother ship decide to develop
advertising solution based on iBeacon and develop an application with this
goal. To make this application, they will never chose to use a SDK specific
to one small implementer with no guarantee over the time.

Rational choice ask to use only standard based solution and avoid anything
custom to rationalise software code and allow simple hardware provider
switch based on local law, product availability, public market, etc.

Be really sure about what you're gonna do with this. Estimote beacon have
a good buzz at this time, you're a interesting actor on this market but you
won't lead the run if you make the mistake to limit software developer to
your vision of the product. You must at least do what the standard do. You
can do more, but not less if you wan't to keep an active community.

I really hope you will go back on the right track, I will be sad to never
use your product on a real project.


Reply to this email directly or view it on GitHubhttps://github.com/Estimote/iOS-SDK/issues/9#issuecomment-28900726
.

mighani commented Nov 20, 2013

+1 ygini. Apple recommends to set the UUID to something unique to your own company and use major/minor to further drill down. So the question is to what is it set at estimote? Is it estimote's own UUID for all beacons?
Then how would we distinguish iBeacons from my company to yignis company ? Would i have to encode this into the major id? Anyway we are going away from the standard. In my opinion that would also be a "no go" for production deployments.

+1

+1

+1

The locked UUID is not logical for developers. The only logic I understand from this decision is that Estimote wants to be a global context object store rather than a greate mote platform provider for developers.

Yes, the UUID security is a problem. As long as I can simulate any UUID from iOS, the reasons behind locked UUID is not logical

+1 We want to be able to stick to the standard that Apple presents for iBeacons in iOS 7

berndpl commented Nov 22, 2013

+1

+1

OK guys, we are always looking forward to hear from developers. At the end of the day you are going to change the physical world building amazing contextual applications and are motivated to help you do that.

In the the next beacon OS update we will allow developers to change UUID in a secure way.
Because we are highly dedicated to solve the security issues we will also provide beacons with a new feature that will prevent UUID and triggers hijacking. Stay in touch!

Contributor
macteo commented Nov 26, 2013

Thanks Jakub!

Great, thanks Jakub!

mighani commented Nov 26, 2013

Great News. Thanks!

That is awesome news Jakub. Thank you for listening to the feedback.

The other point near and dear to my heart that was brought up by @ygini was being able to use the Apple provide API for Beacons instead of the Estimote API. Is the UUID transmission in secure mode you previously talked about a configurable option? If this will be a mode that I can configure on/off, I will be purchasing some of your beacons today.

ygini commented Nov 26, 2013

Thanks Jakub! It's good to see projects close to their client needs :-)

@rickdahl: yes, the security mode will be an option to turn on/off

heyjoey commented Dec 2, 2013

what a relief to know I can update the UUID, thanks!

mknippen commented Dec 6, 2013

+1

mknippen commented Dec 6, 2013

Is there an approximate release date in mind for this? Will we have to update the firmware of the beacons?

gvwert commented Dec 8, 2013

Lovely news! I am too looking for a UUID change. Do you have an SDK roadmap available and/or milestone dates in regards to new SDK releases?

dwery commented Dec 9, 2013

Please understand that some of us might need to change the UUID/maj/min of hundred of devices, so please provide a way to do it via standard Bluetooth LE calls, so that we can write automation software for it.

This is pretty simple, just provide a security key for each order and have a procedure like this one:

  • turn on the beacon

  • within 30 secs, the user's writes the security key to a specific characteristic

  • then writes the new UUID/maj/min to another characteristic

  • reboot

    This should be simple to implement and prevents anyone to
    hijack them.

Hi all, strange question, but am I able to use other beacons with the Estimote SDK or must all of my beacons come from Estimote?

Contributor

SDK supports only Estimote Beacons.

ygini commented Dec 10, 2013

@bbmacster if you use specific upcoming Estimote feature (i.e.: on board captors) you have to use Estimote SDK who work only with Estimote beacons.

If you just need beacons, you can use the native framework for iBeacon on your system (like the one in CoreLocation for iOS). In this case you only have location awareness capabilities but not linked to a specific provider.

Thanks @martinklimek and @ygini . What if I program the UUID to the same UUID that the Estimote beacons have (B9407F30-F5F8-466E-AFF9-25556B57FE6D)? I am hoping to order Estimote beacons in bulk, but I'm not sure I will get them in time, so I thought I could order other beacons and change their UUID and continue using the Estimote SDK.

ygini commented Dec 10, 2013

@bbmacster but why do you want to use EstimoteSDK if you've various provider? EstimoteSDK is useful only for Estimote advanced features. You don't need it for basic geofencing features.

Ahh I see. I was just hoping to use the alternative beacons as a temporary solution to the delay in delivery. Sounds like it might be too much hassle. Anyway, I dont want to clog this forum with my question, just wanted to throw it out there. Thank you all!

Are there Beacon devices available that can be used in a Native iOS App environment with any back end that supports the App/beacons?

I'm a bit late on this topic but want to add that I'm also happy that it will be possible to take full control over UUID, major and minor.
Otherwise I would have stopped here. I think the full beacon support (like stable background operation) will only be available in the general iBeacon functionality provided by Apple.

mknippen commented Jan 9, 2014

Any update on this? Last I heard, it was going to be ready a few weeks ago.

Any update? We are in the final count down in the hardware selection process, estimote is really well positioned but without security and UUID customization this will be a "No Go".

sokol8 commented Jan 14, 2014

Hi guys, I'm must be really off topic with this - but what are "estimote advanced features" and "board captors"? I've played with estimote SDK and beacons a couple of months ago but since then there was a pause. We're about to buy beacons for a pilot so I'm back to the topic.

Contributor

Hi All,

I just wanted to update you briefly about UUID change update. As we informed you before, we are going to allow all developers to set UUID freely. This change is not as simple as it sounds so it took us some time to do it. We need to update our SDK, Firmware and Virtual Beacon application in App Store to be sure that everything works properly. In addition along with that update we want to give you some security mechanisms so you won’t loos track of your beacons.

I’m happy to tell you that we are going to submit new version of the App this week. Depending on the Apple review time you can can play with new functionality in a week or so (we are going to make it all available to you at the same time).

Best regards,
Marcin

That is really good news! What about the SDK?

Williams Martínez

On 16/01/2014, at 3:52, martinklimek notifications@github.com wrote:

Hi All,

I just wanted to update you briefly about UUID change update. As we informed you before, we are going to allow all developers to set UUID freely. This change is not as simple as it sounds so it took us some time to do it. We need to update our SDK, Firmware and Virtual Beacon application in App Store to be sure that everything works properly. In addition along with that update we want to give you some security mechanisms so you won’t loos track of your beacons.

I’m happy to tell you that we are going to submit new version of the App this week. Depending on the Apple review time you can can play with new functionality in a week or so (we are going to make it all available to you at the same time).

Best regards,
Marcin


Reply to this email directly or view it on GitHub.

@martinklimek
Glad to hear that! Anxious waiting ;)

Alex

snooc commented Jan 16, 2014

@willie01ar Your email signature showed in your reply -- It has your phone number, you may want to edit your comment!

Thank you!

Williams Martinez
On 16/01/2014, at 14:09, Cody Coons notifications@github.com wrote:

@willie01ar Your email signature showed in your reply -- It has your phone number, you may want to edit your comment!


Reply to this email directly or view it on GitHub.

Contributor

@willie01ar as we need to keep consistency of the platform from now on SDK is going the be updated with AppStore Virtual beacon app. So the will came out at the same time.

Fantastic. Thank you.

"That means that anyone can change the UUID of your beacons using our SDK. Authentication is coming soon in a future update."

I think the old locked-UUID situation was better. It is not logical to deploy as is. Do you have a timeline for the Authentication update?

Contributor

Hi @ALVBT, we are pushing changes as we have them implemented so you can work with the most current version. Current beacons are not intended to be deployed in the commercial environment. We are currently shipping devkits that allows you can play with the beacons and make prototypes. We are going to distribute final, certified and secured version of the beacon later this year.

ygini commented Jan 28, 2014

@ALVBT Don't forget that iBeacon can always be spoofed. It's an advertisement-only services if we take the standard. Just like GPS. And just like GPS it can be spoofed.

You must need to deploy security procedure on your side. It's not really a provider problem.

@martinklimek, @ygini thank you for your information.

@ygini spoofing is not a problem. But if we put a beacon on a shop, and someone comes and changed the UUID, we have a problem.

Guys,

first of all thanks a lot for the initial discussion around UUID customizing.
As you know from our blogost it is now possible using our latest SDK: http://blog.estimote.com/post/74816977799/estimote-app-v1-2

We are working on anti-spoofing problem and should be released soon.

@ALVBT I see your point and don't worry much about it - now when the new Estimote iOS app is released
it will be easy to update the firmware and we are pushing really hard to make sure the next firmware will consist of authentication compontent. Stay tuned!

Implementing the ability to change the beacon's UUID in the firmware made the beacon usage insecure. You're suggesting that as a developer we should implement a security layer on our end, but that still makes the beacon vulnerable.

Using your own SDK and a spoofing software, anyone could change the beacon's UUID and other settings, that means that even if we have a security layer implemented we would not be able to scan for our beacons because the UUID we're searching for has been changed.

Did I understand this correctly ? If so, do you plan on implementing some kind of security layer in the firmware ?

Contributor

Hi @rolandjitsu,

You are right that there are some security issues right now and we are going to address them soon. There will be an update of firmware and SDK to solve that problem.

Best,
Martin

@martinklimek That sounds good. I assume you will implement some kind of basic authentication in the firmware and some way to manage it in the SDK.

Hi, just to check is the UUID encryption/decryption mode enabled for the new SDK release ?

sokol8 commented May 2, 2014

any new ways to introduce authorisation, connecting to beacons?

ygini commented May 2, 2014

Guys, remember that iBeacons are just beacon. Like a GPS satellite or ATC beacon…

If you need encryption and security, it's maybe not the technology you're looking for…

sokol8 commented May 2, 2014

One can jam or impersonate GPS satellites signals but one cannot alter data (UUID, major, minor) or transmission properties (power, advertising interval) of the that satellite.

For wide-scale production use I expect some ways that only developers (engineering staff) can alter properties of the beacons, not anybody having Estimote app in his phone, right?

ygini commented May 2, 2014

It depend if you want security or fake security.

Yes, being able to put the beacon in readonly mode is necessary, but before thinking to a wide scale production you must be careful, this tech is too young at this time for usage where you've to think about security and reliability.

I've made a lot of work around iBeacon since it's out, and all I can say actually is: don't rely on it. Use it, but not as a main feature, you must be able to work without it.

sokol8 commented May 2, 2014

@ygini Thanks for your warning. I've seen you did a lot of hacking around beacons. Thanks for the 100ms advertising interval info you posted somewhere here too.

There's a lot of manufactures in the market, and more to come. I expect in some 6-9 months there should be more production ready implementations. I also expect to see Estimote among them, so I'm really interested what they will offer us.

ygini commented May 2, 2014

Hope it will work better for you. I've work on home automation and indoor localisation based on iOS and Estimote beacons, and I've dropped out. Even with iOS 7.1, it's nothing close to accurate or functional.

sokol8 commented May 2, 2014

what were the biggest challenges you encountered? non-deterministic beacon coverage areas and sporadic regions enter/leave events?

ygini commented May 2, 2014

Essentially three problems.

The first is on the iOS SDK. the iBeacon implementation on CoreLocation is accurate most of the time but incredibly slow. I have to wait for seconds to actually get a region notification… And when you do ranging, one update per second is too slow.

The second is also on the iOS SDK, not being able to do ranging in background is a pain in the ass. You can't do indoor GPS with that. Background task don't change anything.

The third one is the sporadic regions enter/leave events. And I stop working on this tech at this point. If I let my phone all the night next to the beacon, on the morning I've got multiple in/out events. I need a spectrum analyzer like Chanalyer and a Wi-Spy device to find out if the problem is on iOS side or Estimote side. Since it's not a priority project for me, I've let it down. It take me too much time to debug others products.

J0nnie commented May 8, 2014

@martinklimek Can you give an update on the security issue regarding being able to change the Uuid and the major and minor without any authentication?

zdennis commented May 20, 2014

I'm not jumping in here to toot a competitor's horn, just pointing out some other possibilities that exist in this space. I work on the Gelo ( http://www.getgelo.com ) beacons.

@mighani, @sokol8, @ygini, and others: It is possible to securely customize the UUID, Major, Minor, advertising channels, advertising interval, configuration passcode, transmission power level, and to perform a factory reset on Gelo beacons.

This functionality is only available in configuration mode. 99.9% of the time the beacon is in broadcast-only mode and it's not possible to make any changes to the beacon. This not only reduces battery consumption, but it also means beacons in the wild will not be arbitrarily changed.

The configuration mode can be accessed via a physical magnetic switch which enables configuration mode and allows a person or device to configure the beacon. All services and characteristics are locked down unless you authenticate and are authorized. There is a two-factor approach here. The first resulting from a passcode that needs to either be human entered (on iOS) or that could be scripted (if you want an automaton approach).

Every beacon has a different passcode (obviously there will be sporatic duplication because the passcode range is 0 ~ 999,999 and you may have over a million beacons). The passcodes are NOT hard-coded but are set using a Gelo-specific algorithm based on a number of factors to prevent collisions or reproducibility. Gelo provides you with access to the passcode of your beacons so you can do what you want with them in a secure fashion

@dwery: Gelo beacons act in a similar fashion to what you describe. Our configuration mode will restart once you're done configuring or after a specific number of seconds.

You can use the GeloSDK to interact with beacons but you don't have to. It's all basic bluetooth le. The GeloSDK makes it easier to access text, audio, and video content associated with your beacon if you take advantage of the Gelo platform. The platform also helps manage your beacons. There's no reason you have to use the GeloSDK unless you want to take advantage of that.

We have also been researching and working with a client on anti-spoofing and encryption techniques which minimizes power consumption but also protects the beacon, its advertisements, and its payload from someone who would want to intercept, act as your beacon, or change your payload in the process. There are some trade-offs we've taken into account, but it's a far more secure solution than rotational UUID approaches we've seen others implement.

The Gelo beacon configuration application is not yet in the app store. We are providing the source to those use are interested in evaluating it.

I am not knocking Estimote in any way just trying to add more information to the conversation. Estimote is not the only beacon maker and much of what is being asked for already exists. Continue to evaluate estimote beacons but also please evaluate other beacons which may prove to have what you're looking for.

dwery commented May 20, 2014

@zdennis thanks for doing it right

sokol8 commented May 21, 2014

@zdennis thanks for chiming in. Gelo looks interesting and adds one more option to choose from among a dozen of others.

how is 2 factor auth is organised? The passcode is the first step. What's the second? magnetic stripe?

zdennis commented May 21, 2014

@sokol8, yes, but in the reverse order, magnetic switch first, then passcode. There's another step in there, but that's related to authorization and not authentication.

@patcon patcon referenced this issue in Estimote/Android-SDK Oct 6, 2014
Closed

Encrypted uuid's for android sdk? #81

katzlbt commented Dec 6, 2014

What is the difference? If a hacker changes the major/minor he can do as much damage as when he changes the UUID: Result: the beacon is no longer recognized. So the whole discussion about encrypted UUIDs is pretty useless?

The only advantage of fixed UUIDs is that you may get a database query over your app with an unknown major/minor IF your system has a server. The best solution are USB programmable iBeacons, or ones that only can write UUID,major,minor when a jumper is closed on the device.

Anyway, it is much easier to physically steal the beacon, than to hack it :-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment