Re: Subscription Request and Question.

I'm happy to look into doing a tutorial/app on this once I'm done with the ADC, I2C and SPI ones. I could then roll it all up into the iOS demo app as well if folks think that would be a useful addition. Best regards, dg -- I'll take credit For the funny typos, the rest I blame on the iPhone

Re: Subscription Request and Question.

+1 I think even a PSK example would be helpful. On the NRF52, I think it would be practical to run DTLS over the transport, even if a bit heavyweight. It would be great to have an example of that. Speaking of this, I was wondering if folks had experience with embedded TLS libraries.

Re: Subscription Request and Question.

On 3 Dec 2016, at 6:38, Kevin Townsend wrote: On 03/12/16 11:54, Tim Hutt wrote: Android and iOS don't allow you to specify the keys used by BLE's native encryption, but there is nothing stopping you using BLE as an insecure transport and implementing your own encryption on top of it (well

Re: Subscription Request and Question.

Android and iOS don't allow you to specify the keys used by BLE's native encryption, but there is nothing stopping you using BLE as an insecure transport and implementing your own encryption on top of it (well apart from time, skill, and flash & RAM constraints). If you did that you would be able

Re: Subscription Request and Question.

Well those are bad news I guess. Tim, sorry to be so persisten with this but again, if neither Android nor iOS allow you to specify your own keys, how can you use pre-shared keys? If I understood correctly, I can install a unique key on each device at manufacture and keep a copy of it in the

Re: Subscription Request and Question.

On 2 December 2016 at 17:09, Christopher Collins wrote: > Sorry if I missed this earlier in the thread, but will iOS really let > you use an external key for BLE encryption? Just based on my limited > experience with CoreBluetooth, I wouldn't expect this functionality to >

Re: Subscription Request and Question.

Hi Rodrigo, On Fri, Dec 02, 2016 at 12:30:12PM +0100, Rodrigo Lorenzo Leal wrote: > OK so pre shared key is my best option I guess. > > What I don't understand is, if is possible to have pre-shared key, that is > accesible through the cloud, why I cannot generate a key on the cloud and > access

Re: Subscription Request and Question.

On Fri, Dec 02, 2016 at 10:59:13AM +, Tim Hutt wrote: [...] > (there are supposed to be native Channel-Oriented Connections coming but I > wouldn't hold my breath). Just a small clarification: connection-oriented channels were already added in bluetooth 4.1. However, Nimble doesn't support

Re: Subscription Request and Question.

OK so pre shared key is my best option I guess. What I don't understand is, if is possible to have pre-shared key, that is accesible through the cloud, why I cannot generate a key on the cloud and access it doing a request, from both the app and the device (through GPRS). Maybe is not a OOB

Re: Subscription Request and Question.

On 2 Dec 2016 10:52 a.m., "Rodrigo Lorenzo Leal" wrote: > > Tim. > > Thanks for the reply! So there's no way for the BLE library on iOS and > Android to get the key from an external source? (like a server request) and > use that? Correct. > Also, how does an in house

Re: Subscription Request and Question.

Tim. Thanks for the reply! So there's no way for the BLE library on iOS and Android to get the key from an external source? (like a server request) and use that? I'm more experienced on the firmware/peripheral side than in the app one (I just did some minor test projects on Android). Also, how

Re: Subscription Request and Question.

Yes I know it is only against the pairing phase (I did say that in my previous email), but as Rodrigo said you can (apparently) force re-pairing so that is a small comfort. And I have read the spec and as far as I can tell, Francisco Corella is correct: 'LE Secure Connections' in BLE 4.2 uses the

Re: Subscription Request and Question.

Rodrigo, GPRS will allow you to avoid MitM, but you'll still have to do your own crypto unfortunately because OOB isn't supported on iOS or Android. Also you might want to check if GPRS itself is secure! I expect it probably isn't but you may not care about that depending on your paranoia level.

Re: Subscription Request and Question.

Hi guys! This is actually a problem we will need to solve in the product I'm currently developing at my company. In our case, we have a peripheral with no screen or I/O capabilities that connects to an app via BLE. As I understand it (and mike explained very well in his videos), once the key

Re: Subscription Request and Question.

Your link confounds different Bluetooth versions and different attacks. The TL;DR: LE Legacy Pairing is broken and has been known to be broken since its inception. I wrote on it in 2013[1] and released crackle[2] to demonstrate it. LE Secure Connections address all the weaknesses of legacy

Re: Subscription Request and Question.

See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/ Basically its a mess. As far as I can tell, the actual encryption (AES-128 CCM) is fine, but the key exchange (pairing) methods are all broken in various ways. Just Works is vulnerable to MitM by design (a reasonable trade-off for the

Re: Subscription Request and Question.

This is the first I've heard of LE Secure Connections having any weakness. Can you elaborate and/or provide a citation? On Wed, Nov 30, 2016 at 12:23:06PM +, Tim Hutt wrote: > Just in case you weren't aware, OOB is not available on iOS or Android > (except via NFC). Also all BLE pairing

Re: Subscription Request and Question.

On Wed, Nov 30, 2016 at 08:08:58AM -0800, aditi hilbert wrote: > Rodrigo, > > The NimBLE description is accurate. Mynewt offers SM. The second one is > woefully outdated - I’ll fix that today. > Yes, NimBLE supports OOB. A small clarification - nimble supports OOB for legacy pairing, but not

Re: Subscription Request and Question.

Rodrigo, The NimBLE description is accurate. Mynewt offers SM. The second one is woefully outdated - I’ll fix that today. Yes, NimBLE supports OOB. Yes, we support over the air upgrade via BLE. Sorry there is no tutorial on it yet but we can certainly help you with that. thanks, aditi > On

Re: Subscription Request and Question.

Just in case you weren't aware, OOB is not available on iOS or Android (except via NFC). Also all BLE pairing methods except OOB and Numeric Comparison (which requires a screen) are apparently broken in various ways, even with LE Secure Connections. If security is really important I would

Subscription Request and Question.

To whom it might concern. My name is Rodrigo Lorenzo Leal, and I'm the lead hardware and firmware developer at Pilloxa . We're currently using the Nordic nRF52 with it's SDK and recently discovered ynewt. We're really exited about it and will give it a try.Additionally I