I'm pretty confused concerning the terminology used by IBM. I'm currently working with Watson IoT and embedded devices using MQTT. As you know, embedded devices sometimes do not have the capability to secure a connection via certificates (former SSL). Watson IoT therefore offers a secure connection (?) called "TLS with authentication token". That's what's confusing me. I learned that for a SSL (now TLS) connection you need to pass certificates to the server. How can you establish a TLS connection just by using/sending a auth token? Or do they just mean the authentication process instead of a secured and encrypted connection?
Thanks in advance and have a nice weekend!
If you're using MQTT, the simplest way to connect your device to the Watson IoT Platform is as follows:
When you register your device, you define (or get given) an authentication token - in effect, a password for that device. You have two main options on how you use this token to connect the device to Watson IoT Platform at orgId.messaging.internetofthings.ibmcloud.com:
Port 1883 (this is non-TLS)
Port 8883/443 (this is TLS)
In both cases the password is used to authenticate your device - but only in the second is the on-the-wire traffic encrypted (which is why we strongly recommend using TLS/port 8883/443 where possible). The encrypted connection is over TLS: Watson IoT Platform presents a certificate to allow your TLS-enabled device to validate the certificate and hence trust it's talking to Watson IoT Platform.
There are further options to build on this. You can configure device certificates (e.g., see here) - but I haven't discussed these as - hopefully! - I'll have answered your question using the simple patterns above. Further details on connecting to the platform are available here.
Links correct at the time of writing
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
I have a problem with insecure SSL certificates. My proyect consist on two parts:
ESP32 iot device with a https server
VUE2 + Vuetify PWA web app deployed to firebase hosting.
Imagine that one client buy my iot device, and connect it to the power. The device will boot in AP mode, creating a WiFi AP net.
The client login to the web app and wants to add his new device. So, for that, the iot device needs clients wifi credentials.
The web app asks to the client his ssid and password, and when the client click on 'Configure device', the web app send a https POST request to the esp32 server, and here is the problem...
Because the SSL certificate used in esp32 server is not validated by an authority, the web app can´t make the POST request...
How can I get a valid server SSL certificate for a lot of iot devices? I don´t know how to manage this situation...
Thanks everyone!!
It is possible to get a valid SSL certificate for the device, but I wouldn't recommend it. Here is how you could do it if you wanted to:
Ensure that when your device is in AP mode, it's always available at the exact same IP address. For example, ensure that the ESP32 is listening at 192.168.1.1.
Register a domain like example.com. Add an A record to your DNS server for iot.example.com, with the value 192.168.1.1.
Obtain a valid SSL certificate for iot.example.com from any trusted authority. Put that certificate and associated key on your device.
Now, when your user connects to your soft AP, they can browse to https://iot.example.com and actually see a valid certificate.
However, I would really recommend not doing this. You'll have three major issues to contend with:
The key for your SSL certificate will be on your device's flash. If anyone extracts it, they can masquerade as iot.example.com. You can mitigate this by using flash encryption, but it's still not great.
The maximum validity period for an SSL certificate is around two years. So your provisioning flow will break after a couple years.
If the CA that issued your certificate hears that the private key is floating around and could potentially be compromised, they will probably revoke your certificate.
Instead, what you should do is secure your soft AP with WPA2, and a password that you can give to users. This will ensure that the connection is encrypted, and you can serve your provisioning form over HTTP instead of HTTPS.
An even better approach rather than trying to implement this yourself, is to use the ESP-IDF unified provisioning API. It takes care of the implementation details, and supports both Wi-Fi and Bluetooth as transports.
Regardless of what you decide to do, I'd highly recommend reading the ESP-IDF documentation on unified provisioning and the documentation on Wi-Fi provisioning, since they'll give you an idea of what's going on under the hood and what all is required for a secure implementation. In particular, you'll see that the Wi-Fi provisioning library does actually use a static WPA2 password like I suggested above.
I am looking for device authentication where
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
Each device will have a unique certificate that cannot be transferred to other devices.
A device certificate can be revoked anytime.
To achieve the above, I am planning to have another Service which would issue certificate to devices which is approved to use my service. I will issue the certificate via email to the user where he will install it manually. My users will use browser to access my service.
But I am not sure how would I achieve points 2 and 3.
Can you please guide as to how to achieve this using a self signed certificate?
I want to make sure that all calls to my web service\Website (hosted on Google App Engine) Is coming from an authorized device only, using a device certificate.
You can use a SSL channel with client authentication or adding a digital signature to your messages
Each device will have a unique certificate that cannot be transferred to other devices.
it is not possible to ensure this using software certificates. If you distribute them by email, the user could install them in several devices.
You could use a hardware token (nfc/bluetooth) or preinstall the certificate in the Android/iOS KeyChain so it would not be extractable. but this complicates the distribution very much.
A device certificate can be revoked anytime.
Check revocation at server side before accepting a request from a client. There are standard protocols to do this ( OCSP, CRL), or use a custom mechanism since you issue them yourself
I am doing some research on IBM graph and couldn't find the type of encryption used at both rest and transit. Thanks in advance
IBM Graph's client-facing APIs are only available via HTTPS w/ modern TLS versions. On the backend, data at rest is encrypted via LUKS, and data in motion is encrypted via TLS.
i'm trying to improve the security of our network by disabling our legacy WPA wifi aps. All account are on the network so computers needs network connection to authenticate users.we have now only EAP-MSCHAP V2 scure Wifi (user/password auth), so laptop are not on network when user is not logged in... Our policy is to avoid storing auth information on the computer (pass). So my question is : is there a way to authenticate user on the EAP wifi and then on the domain ?
Laptop are Macs (10.6 to 10.8) and Windows (XP/7).
Thanking by advance!
Cheers
what you would like to achieve is usually done by using 802.1X: http://en.wikipedia.org/wiki/IEEE_802.1X.
A possible solution could look like this:
Each client/notebook (not the user) has a certificate from a common trsuted source (a PKI)
The client request a connection on your 802.1X Access Point who forwards the Request to a defined authentication service (usually a wireless controller and subsequently a radius server). This can be done by EAP protocol for example.
Depending on the authentication result, the client can connect.
In this scenario a certificate is used so that the client/notebook can connect before any windows login happened.
Hope this helps to get you started.