I have designed a BLE peripheral into a product. There will be an app developed (Android, Windows) but for now I am writing firmware to support the app in the blind.
We cannot have someone access the peripheral who is not authorized. To handle this I have a password stored in firmware.
There are seven custom characteristics, all but three of which are disabled upon initial connection. The password characteristic is write only of course, once the correct password is sent the other characteristics are enabled.
I have no experience with BLE until now so I have no idea if this scheme is reasonable or not.
Is there a bettor way to limit access?
Thanks
Rich
The Bluetooth standard defines the pairing/bonding concept with its corresponding encryption. Based on your specification it doesn't seem like it fits your needs.
You therefore have to come up with something on your own. How secure you make it is completely up to you. Your proposal is the simplest and most unsecure way of doing it. The most secure thing you can do is use some protocol created for these purposes (https://en.wikipedia.org/wiki/Password-authenticated_key_agreement) to create a cryptographic key which you then use for authenticated encryption when you later communicate with your device. You decide which way you want to go based on the security level you want.
Related
I've my C# NET6 desktop application to send to customers, important functions have been removed and implemented on a server
I've my public server on which I want to auth desktop app(license, feature...), get its blob, process it, send back
I consider the C# app crackable whatever obfuscator/protector I'll use (but i'll use anyway), server is considered secure, i need a secure point at customer premise.
The idea is to use an usb dongle to bring up a secure and authenticated session between desktop app and server.
Requisites for the dongle are:
Be able to do AES128(at least) and/or RSA1024(at least)
EAL5+/6+ secure MCU (nothing that could be dumped with glitches or baths in acid)
dll and API to talk with
So far i've looked at various sw protection dongle, but:
some are 15years old mcu and not sure if still in business
most doesn't tell what mcu is inside, some are fast (but silly) stm32, some are slow 8051
the expensive ones are the most complex ones, i mean it takes days to read unclear documentation and see that i don't need 90% of the package (enveloper, mssql db for my 50customers...)
i don't need at all their C# enveloper, I want to use a thirdparty/specific protector with VM
So i've looked at usb tokens PKI, FIDO2, PIV....but:
FIDO2 allows customer to reset pin and cear all certificates, no good as i want to burn keypair inside prior to ship to customer
PIV not found any cheap PIV only usb token, some FIDO2 expensive has also PIV interface, but...
to talk to FIDO2 and PIV i would need all the overload bloat of libraries that i very dislike (and also needs admin right, which i want to avoid)
PC/SC usb token are the most lowlevel to use, mscard lib and do whatever, nice but.....ISO-7816-8,9 are not public, costs like 300bucks to eventually see that my card vendor implemented custom stuff
I've 0x80 blob to send to dongle to powmod() it, that's all, no x509, no pkcs11, no base64, nothing human, just need a powmod(data) or an aes_dec(data).
Any suggestions?
While this is no full answer, I would like to address some issues:
You may underestimate the complexity required. Obviously necessary is some specification, whether RSA or AES operation is required. This has to show up somewhere, either as command parameter or as a set-up command (between host and connected token).
Pure modular exponentiation is unlikely to reach the desirable level of security, since RSA depends on padding to exclude some kinds of attack.
You may not like PKCS 11 interface, but it is proven and known to introduce no security issues. This may require notable effort if done on your own.
Given the mentioned EAL levels, my guess would be, that you need a smart card chip with USB interface.
The MCU is pretty irrelevant: to get crypto operations hardened, you need special hardware (as cryptographic coprocessors). It has little influence, how old the architecture of the chip is, which feeds the bytes to those.
We are developing sensors which will be distributed in large quantities and broadcast BLE every 5s in order to have access to DFU and Data Sending. The DFU is encrypted from the manufacturer's end however the Data Sending (NUS/UART) is left open and so we are looking for ways to encrypt the data or limit access to this service from unwanted users. A static PIN key could be used however since it is only 4 digits long (usually), there are only 10,000 combinations. It would be appreciated if you could shed some light on this.
The Bluetooth standard won't help you solve this in a good way. Its pairing / bonding features are designed to prevent remote attacks while a user is pairing with the device, not to prevent any person from pairing at all. You should see the question as a general question and not a Bluetooth-specific one in my opinion.
Unless you want to pre-bond all the sensors to some legit device and then prevent new pairings (which would of course solve your problem, but might be cumbersome in practice), you should use something else than what the Bluetooth standards offers.
For example, if you are happy with having a password to access the sensors, you can implement a PAKE scheme (https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement) and then encrypt and sign all data using the derived key. You can also simply use TLS, or some other certificate-based solution.
If you are lazy and think it's too hard to implement proper cryptography you can otherwise just have a characteristic that the user writes a password to, and if it's accepted, the data sending service opens up. This of course is unsecure because an attacker can sniff the connection and find the password. The same applies when you have a static PIN and use standard Bluetooth pairing.
I have some Bluetooth LE v4.2 beacons that I will connect ONLY with known devices that we may call "readers". The beacons are program and installed by me. I consume the data and I sell the service.
I want to use a hard-coded shared secret to realize the pairing or communication. My primary concern is that only a known and authenticated device SHALL be able to send data (with integrity protection).
What would be my best option ?
A few previsions :
We are talking about 1000s of devices, and more will join the network every day.
I am already doing advertisement filter, etc. I only connect to devices with my vendor id.
Replacement if preferable to any kind of lack of security in the authentication, my added value is the trust in data.
I have an OTA update system for all the devices.
Interesting documentation I found about Bluetooth Low Energy (BLE) security :
NIST Guide to Bluetooth Security
An answer to my question on the Nordicsemi devzone gave me some hints. Find below the answers I was looking for. I hope that will help.
Mode 1 Level 4 (encryption) vs Mode 2 Level 2 (signing)
Resources :
Dev zone semi question
Forget about CSRK. It's a bad idea that almost no BLE stacks support. One reason is that it only supports Write Without Response in one direction. Another is that you need to keep a write counter stored in flash. A third is that a MITM could potentially delay a message for an arbitrary time and doesn't need an active connection during this time. It has no benefits at all compared to the normal AES-CCM except that CCM takes 2.5 round trips to set up for BLE.
How to ensure secure encryption with a pre-shared secret
Resources :
Dev zone semi question
Stackoverflow question
Dev zone semi : Pre-shared key = OOB
Dev zone semi : OOB LESC vs Legacy
Do we need pairing ?
No pairing :
If you remove the pairing step from BLE security you basically just have AES-CCM with pre-shared keys, where each connection has an own key derived from the shared key and a nonce from each side. LESC is about the pairing step which you want to remove, so that doesn't apply in that case.
Vs Out Of Band (OOB) :
A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing.
Preferred solution is Out of band pairing.
LESC with pre-shared passkey vs OOB with pre-shared key ?
Resources :
Dev zone semi : Pre-shared key
The first time you connect you should authenticate the other device, and you can do this by using your pre-shared key when you bond. You can bond by using Passkey Entry or OOB. The key used with Passkey Entry is short, so I would recommend using a 128-bit key with OOB, this is much more secure.
Out of band LESC Vs Out Of Band Legacy
Both LESC and Legacy end up with 128-bit encryption keys, and these are equally secure. The power consumption will be the same after pairing is done. LESC uses a more complex algorithm so it will use more power during the pairing process. The difference is in the key generation algorithm. It depends on what kind of attacks you want to protect against. If you do OOB with legacy and you are sure that the attacker can't get the OOB data, you are secure. If the attacker can get this data, you should go for LESC. What kind of central device are you connecting to? Does it support OOB and/or LESC?
In fact LESC out of band with pre-shared key is quite complicated to archive because of the calculation of the oob payload is supposed to be a random number signed with private key, and this mechanism is implemented in the softdevice but not accessible. Thus we could either re-invent the wheel, or just decide that this computation is useless as evedrop of out-of-band is just impossible with pre-shared key. Also, LESC oob pairing is more calculation intensive for no benefits.
Out of band Legacy
For more detailed explanations of Out of band Legacy pairing, see bluetooth.com.
Temporary key calculation
A master key will be included in the new FW release code (that's probably my major weakness, but I cannot do much about it). I will use legacy Out Of Band pairing. The Temporary Key (TK), used for paring communication encryption, will be derivated from the master key using generation function fc (inspired by the f5 function described in the Bluetooth specification).
The definition of this key generation function fc makes use of the MAC function AES-CMACT with a 128-bit key T.
The input of the function are:
M is 128 bits
A1 is 56 bits
A2 is 56 bits
The string “******” is mapped into keyID using extended ASCII as follows:
keyID = 0xXXXXXXXXXXXX
The output of the key generation function fc is as follows:
fc(M, A1, A2) = AES-CMACM(keyID || 0x00 || A1 || A2 || Length = 128)
The TK is calculated as:
TK = fc(Master key, DB_ADDR_master, DB_ADDR_slave)
I wouldn’t pair in factory, but instead add other programmatically controlled mechanisms in the FW. I’m thinking bondable LE links, whitelisted MAC-addresses (as long as we’re not talking about random/obfuscated addresses).
If you have access to the chip/design in production, you could let the production test station use wired/wireless available interface and add the whitelisted MAC addresses in there...?
Or, use Vendor-specific data in the BLE advertisements data and add X identification bytes that you filter on in the LE central.
Or, use groups of custom Service UUIDs and add to the adv data, allowing centrals to filter on that.
Etc etc — the point is; my experience of setting production pre-paired stuff has always ended up in chaos, and there should always be a mechanism to clear your pairing and manually setup thing as you, or your customer, want. How else would you deal with replacements, upgrades etc and sudden implicit or explicit breaking changes — always design things so that there’s a way to get thing up and running from scratch again. Depending on the product, that might be using a Config tool from PC, or Admin-mode from your phone/app, or the like — but don’t rely on production-defined pairings.
I am trying to develop a custom cryptographically secure protocol for authenticating through an RFID smart card, all I can find over the internet are generic info on how write static Tags into the card.
For my project I need for the reader to send a Challenge nonce to the card (fixed length random bytes), then the card should send back the challenge encrypted with the hard-coded key (for example with AES CBC) or an hash HMAC.
The problem is: how can I program the card to do such behavior? I can write the code to do so, but how to "flash" it to the card. Also the code for the reader is not a problem (I want to use an Arduino with a reader module).
And then has a passive chip enough power to do this kind of calculations or is better to use an active one, considering that the distance would be few centimeters, such as behind a door?
A passive tag can't do this. Those just hold serial numbers that they spit out back.
You need some smarter card. You have basically two choices:
1) Choose a general-purpose card that fit your needs
The authentication scheme you describe is very widely used, and implemented by virtually all general-purpose smart cards, whether with contact or contactless (RF) interfaces (or both). If you go this way, you don't need to program the card with your own code, you just need to get the specs and initialize the card with the key value you want by sending the appropriate commands. And actually, with these cards, there are often generic tools available to initialize them. Easy.
Mifare (by NXP), for example is very widely used, easily available, and cards are cheap (drawback: it is certainly not the most secure cards ever made). You could use Mifare Classic - with proprietary NXP security protocol - specs here (be careful, the reader must be compatible) or Mifare UltraLight C, with open 3DES crypto - specs here. There are other variants, as well (e.g. Mifare Plus, which uses AES). Just don't go for the simple Mifare Ultralight, which doesn't provide authentication means. You'll see that for all these type of cards, there is a builtin authentication scheme that can functionally fulfill your needs (it is actually a mutual authentication, so it does more that what you require, but it's fine).
FeliCa (made by Sony), ACOS3 (made by ACS - specs here) are other possibilities, although I'm less familiar with it.
2) Get programmable cards
There are some, but it is not very easy to find for contactless and they are very expensive. You can lookup:
BasicCard (ZeitControl), which exist with dual interface. Those cards are programmable in Basic, and there are some kits available (but I'm not familiar with it either).
JavaCard (any manufacturer), which is a standard, but those are hard to find for small volumes. A few online shops seem to have some, though. These cards are programmable in Java (actually a subset of Java). There are tools available for the development phase (from Oracle, or even as Eclipse Plugins, for example). Then, for loading your custom applet in the smart card, you need to get familiar with GlobalPlatform, which is another (publicy available) standard, describing the way applications are managed in a smart card. This would be too broad to describe in detail here, though. You can find resources on the internet, but this road is definitely the most difficult.
Note, that NFC just describes the communication method and tells nothing about the intelligence available on other side.
More intelligence is needed (the command you seem to look for is called EXTERNAL AUTHENTICATE in ISO 7816-4), but does not help for your range problem, since the weaker the field, the less power is available. The idea of having communication through the door will only work for doors which are so weak, that a high-tech electronic protection won't improve overall security. The maximum distance achievable with standard field strength (heart pacemakers and similar devices limit that one) with nothing more than air between suffices typically for something like 10 centimeters. So for me it seems that your reader has to be on the outside and needs to be mechanically hardened against tampering itself.
(What would help, is a "card" with its own power source, so the field is only required for communication. As far as I know, this is mostly provided by a sort of external sleeve.)
What dim fails to mention is the product group of so-called native cards, which are typically only programmable with significant manufacturer support (non-disclosure agreement, probably fee involved), but luckily contain functionality for most use cases already, in your case the commands Get Challenge and External Authenticate.
Suppose you want to add an extra layer of credentials on top of a SSL-encrypted login/password, but you don't want to increase complexity to the user. Is there a way to add the requirement of the possession of a dongle to web-server authentication schemes with existing cross-platform browser capabilities?
In other words, to get access to the web-site, you would need a username, password, and a USB dongle that has been plugged into the client computer. The dongle would presumably do some sort of challenge/response.
It'd be ideal if this dongle solution worked with Firefox automatically or with the simple addition of a plugin.
Thoughts and suggestions are appreciated.
You may be interested in the Yubikey.
It's a small usb dongle that acts as a usb keyboard (i.e. needs no special drivers or client software) and is designed exactly for this sort of authentication.
You could use RSA SecurID tokens, which are little keychain displays that change the number displayed every one minute. In addition to requiring the username and password, you can also require them to enter the number they see on their token to verify they have the hardware device with them. There are various hardware dongles, with some even requiring a PIN to be entered to see the changing number. The is extra complexity on the server side, but the client doesn't have too much trouble.
I've also used the Yubikey with good results. Another similar solution is the Swekey - you might want to check that out also.
I've had good results implementing website authentication and login using Dinkey Dongles and the DinkeyWeb system.
The user plugs the usb security dongle into their machine, visits your "protected" web page and it validates the dongle before loading the page. Works without special permissions or privileges.
Hope it helps.
It's going to require something that has the rights to access the dongle. There is also the issue of hacking it--the communications aren't going to be able to be hidden so you have to make sure it doesn't matter. That means the dongle is going to have to implement it's own crpyto. You'll also need support for whatever systems you are going to support.
I see this getting very complex very fast.