I'm working on an embedded system running linux for embedded.
The HW has TPM chip. I've made some preparations, I installed the tpm2-tss and tpm2-tools sw libs and I've test them by hashing some data with the TPM. Its worked.
The system is implementing some RF protocol and transmit messages.
The messages are encrypted using AES128 with a secret key that each device have.
I want to use the TPM capabilities to store the key securely on the device and to encrypt the messages before I send them.
I know that the TPM HW is limited, but the data traffic is very low, so I don't see any issue with encrypting the data with the TPM.
There is a lot of information about the TPM, but all this information made me more confused. I need some guidelines and a simple explanation to help me with my needs.
From what I've read the TPM uses a secret internal key to encrypt data and store it on the system external memory. So i'm guess I need to use this feature to encrypt the device key and store it.
I didn't understand how I address my key after that and how I "tell" the TPM to encrypt some data with this key.
I am same problems with TPM2. O TPM2 is so much confused to use tpm2-tools. I recommend use clevis-encrypt tpm2 to abstract complexity of encrypt and decrypt.
If u have news with use TPM2 to sealing boot. I thank if u share here
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 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.
I'm working on the AFC (automatic fare collection) system which required a SAM( secure access module) for key management.system works fine with local key management in MCU and I don't have any experience in using SAM.SAM required to install beside MCU as main reader controller & contactless card reader chip(PCD).
Is used protocol based on the smart card ISO7816?Am i true?
As i know SAMs are part of SMART cards family,are a SAM javacard or there are javacard SAM and non javacard SAM?
is there upper level standard used for communicating with SAMs(based on iso7816 ) or each manufacturer use its own protocol?
whats different between SAM and usual GSM SIM-CARD? and can i use a GSM-SIMCARD instead of SAM?
is there any standard use case for process of key management in smart cards ?
wbr
A SAM may be a smart card or another chip like a trusted platform module. A TPM is addressed using an API, see here.
SAMs are seldom required, so there are no domain independent standards how to address these.
If a smart card is used, then 7816 is obviously the way to go. A native smart card is also perfectly possible as SAM, especially if Perform Security Operation command of ISO 7816-8 is supported.
A typical SAM command is "encrypt these data with your (say AES) key number 1". A typical SIM card will have no command for it.
You have to collect the use cases you are interested in by yourself. Some ideas:
encrypt these data
decrypt this cryptogram
compute or verify this message authentication ocde
derive session key
replace key data of existing key