问题
So, this might be a very special case, but I hope someone can help me out here.
I need to talk to a peripheral via Bluetooth. A device for which we also control the firmware. Now the issue is: we need to make sure noone can eavesdrop as the information to be sent will be confidential. That means we need an encrypted communication.
From what I see is that Bluetooth LE 4.2 supports encryption, BUT we have to be able to support older iPhones than the 6s. That means: no BLE 4.2 and no built in encryption.
In other words: we need to build the encryption ourselves. The peripheral developers and me agreed on using the TLS handshake to communicate the key exchange to reduce the amount of things we could break.
I've spent the last few days searching for solutions and how to tackle this. However this seems to be a very specific case that not a lot of people have tackled. All libraries that I could find rely on sockets. And all I could find about sockets for iOS was IP networking, not Bluetooth.
Does anyone have experience with this kind of Bluetooth communication? Or some other suggestions? Maybe some obvious solution that I'm overlooking?
Thanks :)
回答1:
The whole foundation in TLS builds upon trust, i.e. Certificates, Certificate authorities and certification chains, and making sure all data sent and received are authenticated. You could say the whole security relies on the authentication part. The encryption itself is quite straight-forward. One question you should answer is:
Should it be possible to connect to peripherals that mimic your protocol, i.e. peripherals NOT manufactured by you? If not, with your premises you must have some (unique) secret in each peripheral, for example a private key. The corresponding public key can be signed by your own CA. The public key of the CA can be bundled in your smartphone app (so you need only one key in your app, not one for all peripherals). That way you can verify that the peripheral you connect to is made by your company. This public key should also be the identifier of the peripheral. If you don't have a private / public key pair inside your peripheral and can't do passkey comparison and don't have any shared symmetric key, as far as I know it's impossible to avoid man-in-the-middle attacks.
Since each smartphone must also initially be treated unauthenticated, if you need to resume a session later, you need to store some unique ID assigned to each smartphone in the peripheral.
With this in mind, you have basically three different options:
- Try to modify some present TLS server software like mbedtls to send all packets over BLE rather than sockets. I have a feeling this might be non-trivial because it seems it's based on the concept of blocking sockets.
- Just read the TLS spec on https://tools.ietf.org/html/rfc5246 and implement a minimal TLS server with only the features you need. This is actually not so hard as it may look like first if you only do a minimal implementation and use existing building blocks such as RSA, AES, SHA-2, ECDHE, X.509 certificate parsing code (you can find those here: https://tls.mbed.org/source-code).
- Extract the important parts in TLS and make a simplified protocol without all negotiation parameters (since they can be hardcoded). For example, you don't need to send and be able to parse all kind of messages (for example ClientHello), handle fragmentation etc. Just send the random values, certificates, signed data, encrypted data directly.
来源：https://stackoverflow.com/questions/38662923/tls-like-encryption-over-bluetooth-on-ios