[PATCH] hawkbit: adding authentication using security token

[Ayoub Zaki]

When a target is created within hawkBit a specific security token (32 alphanumeric character) is generated.

This can be used to authenticate the target through a HTTP-Authorization header with a custom scheme TargetToken.
---
corelib/channel_curl.c | 12 ++++++++++++
examples/configuration/swupdate.cfg | 3 +++
include/channel_curl.h | 1 +
suricatta/server_hawkbit.c | 3 +++
4 files changed, 19 insertions(+)

diff --git a/corelib/channel_curl.c b/corelib/channel_curl.c
index 608f5d3..ec412c0 100644
--- a/corelib/channel_curl.c
+++ b/corelib/channel_curl.c
@@ -345,6 +345,7 @@ channel_op_res_t channel_set_options(channel_t *this,
{
channel_curl_t *channel_curl = this->priv;
channel_op_res_t result = CHANNEL_OK;
+ char *token = NULL;
if ((curl_easy_setopt(channel_curl->handle, CURLOPT_URL,
channel_data->url) != CURLE_OK) ||
(curl_easy_setopt(channel_curl->handle, CURLOPT_USERAGENT,
@@ -397,6 +398,17 @@ channel_op_res_t channel_set_options(channel_t *this,
}
}

+ if (channel_data->token != NULL) {
+ if (asprintf(&token, "Authorization: TargetToken %s",
+ channel_data->token)) {
+ if (((channel_curl->header = curl_slist_append(
+ channel_curl->header, token)) == NULL)) {
+ result = CHANNEL_EINIT;
+ goto cleanup;
+ }
+ }
+ }
+
switch (method) {
case CHANNEL_GET:
if (curl_easy_setopt(channel_curl->handle, CURLOPT_CUSTOMREQUEST,
diff --git a/examples/configuration/swupdate.cfg b/examples/configuration/swupdate.cfg
index f9366fd..0d4aba2 100644
--- a/examples/configuration/swupdate.cfg
+++ b/examples/configuration/swupdate.cfg
@@ -101,6 +101,8 @@ identify : (
# path of the file containing the key for ssl connection
# sslcert : string
# path of the file containing the certificate for SSL connection
+# token : string
+# Hawkbit security token
# proxy : string
# in case the server is reached via a proxy

@@ -122,6 +124,7 @@ suricatta :
cafile = "/etc/ssl/cafile";
sslkey = "/etc/ssl/sslkey";
sslcert = "/etc/ssl/sslcert";
+ token = "3bc13b476cb3962a0c63a5c92beacfh7";
*/
};

diff --git a/include/channel_curl.h b/include/channel_curl.h
index 98240a9..156d671 100644
--- a/include/channel_curl.h
+++ b/include/channel_curl.h
@@ -46,6 +46,7 @@ typedef struct {
char *cafile;
char *sslkey;
char *sslcert;
+ char *token;
char *proxy;
char *info;
unsigned int retry_sleep;
diff --git a/suricatta/server_hawkbit.c b/suricatta/server_hawkbit.c
index 175396c..ce5374b 100644
--- a/suricatta/server_hawkbit.c
+++ b/suricatta/server_hawkbit.c
@@ -1527,6 +1527,9 @@ static int suricatta_settings(void *elem, void __attribute__ ((__unused__)) *da
GET_FIELD_STRING_RESET(LIBCFG_PARSER, elem, "proxy", tmp);
if (strlen(tmp))
SETSTRING(channel_data_defaults.proxy, tmp);
+ GET_FIELD_STRING_RESET(LIBCFG_PARSER, elem, "token", tmp);
+ if (strlen(tmp))
+ SETSTRING(channel_data_defaults.token, tmp);

return 0;

--
2.7.4

[Diego Rondini]

Hi Ayoub,

On Tue, Dec 5, 2017 at 10:11 PM, Ayoub Zaki <ayoub...@embexus.com> wrote:

When a target is created within hawkBit a specific security token (32 alphanumeric character) is generated.

This can be used to authenticate the target through a HTTP-Authorization header with a custom scheme TargetToken.

<code-snip>

This is a nice addition, but I have a couple of notes about it.

1. Security Token types

I'd rather call the variables / parameters with the whole name "target_token" rather than just "token", as hawkBit supports two different security tokens: GatewayToken and TargetToken:

http://www.eclipse.org/hawkbit/documentation/security/security.html

You could even add support for GatewayToken straight away, as the header is the same ("Authorization"), just the content / schema is different.

The only thing needed is to provide two separate parameters, e.g.:

target_token = "3bc13b476cb3962a0c63a5c92beacfh7";

gateway_token = "3nkswAZhX81oDtktq0FF9Pn0Tc0UGXPW";

If you don't want to implement support for the GatewayToken I can do it after your patch, but just be specific in the variable name, don't use just "token".

2. TargetToken loading

One thing to keep in mind with this implementation is that:

1. the target needs to first connect anonymously to "plug-and-play" and be assigned a TargetToken

2. the TargetToken needs to be manually inserted in the swupdate.cfg or startup parameters

3. swupdate daemon needs to be restarted

This procedure works for a few devices, but doesn't scale well for lots of devices (or is at least tedious).

So thank you very much for your patch Ayoub, let me know if you want to proceed with implementing the GatewayToken or you want a helping hand.

I hope this feedback is appreciated, waiting for Stefano's opinion.

Bests,

Diego Rondini

Sr. Embedded Engineer

Kynetics
www.kynetics.com

[Ayoub Zaki]

Hi Diego,

On 06.12.2017 10:50, Diego Rondini wrote:
> Hi Ayoub,
>
> On Tue, Dec 5, 2017 at 10:11 PM, Ayoub Zaki <ayoub...@embexus.com
> <mailto:ayoub...@embexus.com>> wrote:
>
> When a target is created within hawkBit a specific security token
> (32 alphanumeric character) is generated.
>
> This can be used to authenticate the target through a
> HTTP-Authorization header with a custom scheme TargetToken.
> <code-snip>
>
>
> This is a nice addition, but I have a couple of notes about it.

Thanks !

>
> 1. Security Token types
> I'd rather call the variables / parameters with the whole name
> "target_token" rather than just "token", as hawkBit supports two
> different security tokens: GatewayToken and TargetToken:
> http://www.eclipse.org/hawkbit/documentation/security/security.html
> You could even add support for GatewayToken straight away, as the
> header is the same ("Authorization"), just the content / schema is
> different.
> The only thing needed is to provide two separate parameters, e.g.:
> target_token = "3bc13b476cb3962a0c63a5c92beacfh7";
> gateway_token = "3nkswAZhX81oDtktq0FF9Pn0Tc0UGXPW";
> If you don't want to implement support for the GatewayToken I can do
> it after your patch, but just be specific in the variable name, don't
> use just "token".

 I didn't use GW Token yet but it seens to be straight forward to
implement, yes of course you can send a patch :-)

>
> 2. TargetToken loading
> One thing to keep in mind with this implementation is that:
> 1. the target needs to first connect anonymously to "plug-and-play"
> and be assigned a TargetToken

Not necessarly, the target can be created using the management API
before actuallly the real device connects to Hawkbit :

[1]
https://docs.bosch-iot-rollouts.com/documentation/developerguide/apispecifications/managementapi/targets.html

The security token is then generated and and can be put on the real
device during the production for example.

Although I prefer using a ssl based authentication using certificates !

> 2. the TargetToken needs to be manually inserted in the swupdate.cfg
> or startup parameters
> 3. swupdate daemon needs to be restarted
> This procedure works for a few devices, but doesn't scale well for
> lots of devices (or is at least tedious).

see above !

swupdate.cfg should be specific to each device : see identify section in
config file, so the best is perform this customization at production time.

>
> So thank you very much for your patch Ayoub, let me know if you want
> to proceed with implementing the GatewayToken or you want a helping hand.
>
> I hope this feedback is appreciated, waiting for Stefano's opinion.

You're welcome.


Best regards,

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile : +4917662901545
Email : ayoub...@embexus.com
Homepage : https://embexus.com
VAT No. : DE313902634

[Diego Rondini]

Hi Ayoub,

On Wed, Dec 6, 2017 at 2:02 PM, Ayoub Zaki <ayoub...@embexus.com> wrote:

<snip>

1. Security Token types
I'd rather call the variables / parameters with the whole name "target_token" rather than just "token", as hawkBit supports two different security tokens: GatewayToken and TargetToken:
http://www.eclipse.org/hawkbit/documentation/security/security.html
You could even add support for GatewayToken straight away, as the header is the same ("Authorization"), just the content / schema is different.
The only thing needed is to provide two separate parameters, e.g.:
target_token = "3bc13b476cb3962a0c63a5c92beacfh7";
gateway_token = "3nkswAZhX81oDtktq0FF9Pn0Tc0UGXPW";
If you don't want to implement support for the GatewayToken I can do it after your patch, but just be specific in the variable name, don't use just "token".

 I didn't use GW Token yet but it seens to be straight forward to implement, yes of course you can send a patch :-)

Sure I will.

Let us know if you plan to change the name of the "token" var / parameter.

 

2. TargetToken loading
One thing to keep in mind with this implementation is that:
1. the target needs to first connect anonymously to "plug-and-play" and be assigned a TargetToken

Not necessarly, the target can be created using the management API before actuallly the real device connects to Hawkbit :

[1] https://docs.bosch-iot-rollouts.com/documentation/developerguide/apispecifications/managementapi/targets.html

The security token is then generated and and can be put on the real device during the production for example.

Sure, hawkBit has the ability to preload the targets.

 

Although I prefer using a ssl based authentication using certificates !

2. the TargetToken needs to be manually inserted in the swupdate.cfg or startup parameters
3. swupdate daemon needs to be restarted
This procedure works for a few devices, but doesn't scale well for lots of devices (or is at least tedious).

see above !

swupdate.cfg should be specific to each device : see identify section in config file, so the best is perform this customization at production time.

Right, as you say, you still need to load the unique TargetToken to each device before it is able to connect anyhow.

Bests,

[Stefano Babic]

Hi Ayoub,

After I moved the curl code outside suricatta / hawkbit, this part is
completely unaware abot the type of connection. It is simply a JSON over
http(s), but without any specific server detail.

That means that the tokens should be integrated in the server part and
simply passed to the channel curl. channel_curl should not know that a
"Authorization: TargetToken" must be sent, because this is Hawkbit
pecific. A different backend will ask for a different header.

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Stefano Babic]

Hi Diego,

On 06/12/2017 10:50, Diego Rondini wrote:
> Hi Ayoub,
>
> On Tue, Dec 5, 2017 at 10:11 PM, Ayoub Zaki <ayoub...@embexus.com
> <mailto:ayoub...@embexus.com>> wrote:
>
> When a target is created within hawkBit a specific security token
> (32 alphanumeric character) is generated.
>
> This can be used to authenticate the target through a
> HTTP-Authorization header with a custom scheme TargetToken.
> <code-snip>
>
>
> This is a nice addition, but I have a couple of notes about it.
>
> 1. Security Token types
> I'd rather call the variables / parameters with the whole name
> "target_token" rather than just "token", as hawkBit supports two
> different security tokens: GatewayToken and TargetToken:
> http://www.eclipse.org/hawkbit/documentation/security/security.html
> You could even add support for GatewayToken straight away, as the header
> is the same ("Authorization"), just the content / schema is different.
> The only thing needed is to provide two separate parameters, e.g.:
> target_token = "3bc13b476cb3962a0c63a5c92beacfh7";
> gateway_token = "3nkswAZhX81oDtktq0FF9Pn0Tc0UGXPW";

It is also to think about how these parameters are put into the
configuration file. Tenant-id are often derived from some device
specific data (serial number, etc.) and passed to SWUpdate at start up.
Tokens (target token) are known when target connects for the first time.

I guess we needalso the way to store back the token after first connection.

> If you don't want to implement support for the GatewayToken I can do it
> after your patch, but just be specific in the variable name, don't use
> just "token".
>
> 2. TargetToken loading
> One thing to keep in mind with this implementation is that:
> 1. the target needs to first connect anonymously to "plug-and-play" and
> be assigned a TargetToken
> 2. the TargetToken needs to be manually inserted in the swupdate.cfg or
> startup parameters
> 3. swupdate daemon needs to be restarted
> This procedure works for a few devices, but doesn't scale well for lots
> of devices (or is at least tedious).

This just works during the development. On large scale, a certificate
based mechanism is much more safe as this one with tokens.

I will expect that tokens are already set for all devices with MKMNT
interface or they are free to have and the devices store permanently the
token the first time they connect.

>
> So thank you very much for your patch Ayoub, let me know if you want to
> proceed with implementing the GatewayToken or you want a helping hand.
>
> I hope this feedback is appreciated, waiting for Stefano's opinion.
>

Best regards,
Stefano

[Ayoub Zaki]

Hi Stefano,

I agree token parameter is very specific to hawbit: it should belong to
server_hawkbit_t structure and passed to channel url.
I will rework the patch, test it and send a new version.

[Diego Rondini]

Hi Stefano and all,

Sorry to resurrect this thread, but I'm about to send a reworked
version of this patch moving the definition of the specific header in
the hawkbit server specific code.
I'm unsure if the approach I've taken is what you Stefano had in mind,
as the channel_data_t struct in channel_curl.h still has an addition.
In this case though I've added a generic "header" rather than a
hawkBit-specific "token". If this is not what you wanted, please
elaborate more about your idea, as the curl header list is defined in
the channel_curl_t as part of channel_curl.c, so not accessible from
server_hawkbit.c.

The other thing I'll need to work on is clearly separating and
supporting both Gateway Token and Target Token, but I prefer to work
on that when the above point is cleared out.

Patch incoming.

Thank you,

[Diego Rondini]

From: Ayoub Zaki <ayoub...@embexus.com>

When a target is created within hawkBit a specific security token (32 alphanumeric character) is generated.

This can be used to authenticate the target through a HTTP-Authorization header with a custom scheme TargetToken.

Signed-off-by: Ayoub Zaki <ayoub...@embexus.com>
Signed-off-by: Diego Rondini <diego....@kynetics.com>
---

Changes in v2: used generic "header" concept in channel_curl code

corelib/channel_curl.c | 8 ++++++++

examples/configuration/swupdate.cfg | 3 +++
include/channel_curl.h | 1 +

suricatta/server_hawkbit.c | 6 ++++++
4 files changed, 18 insertions(+)

diff --git a/corelib/channel_curl.c b/corelib/channel_curl.c
index 0dec551..2f572d4 100644
--- a/corelib/channel_curl.c
+++ b/corelib/channel_curl.c
@@ -385,6 +385,14 @@ channel_op_res_t channel_set_options(channel_t *this,
}
}

+ if (channel_data->header != NULL) {

+ if (((channel_curl->header = curl_slist_append(

+ channel_curl->header, channel_data->header)) == NULL)) {

+ result = CHANNEL_EINIT;
+ goto cleanup;
+ }
+ }
+

switch (method) {
case CHANNEL_GET:
if (curl_easy_setopt(channel_curl->handle, CURLOPT_CUSTOMREQUEST,
diff --git a/examples/configuration/swupdate.cfg b/examples/configuration/swupdate.cfg

index 5c9e122..213f8be 100644
--- a/examples/configuration/swupdate.cfg
+++ b/examples/configuration/swupdate.cfg
@@ -105,6 +105,8 @@ identify : (

# path of the file containing the key for ssl connection
# sslcert : string
# path of the file containing the certificate for SSL connection
+# token : string
+# Hawkbit security token
# proxy : string
# in case the server is reached via a proxy

@@ -126,6 +128,7 @@ suricatta :

cafile = "/etc/ssl/cafile";
sslkey = "/etc/ssl/sslkey";
sslcert = "/etc/ssl/sslcert";
+ token = "3bc13b476cb3962a0c63a5c92beacfh7";
*/
};

diff --git a/include/channel_curl.h b/include/channel_curl.h

index 2133744..b13e9cf 100644
--- a/include/channel_curl.h
+++ b/include/channel_curl.h
@@ -37,6 +37,7 @@ typedef struct {
char *sslcert;
char *proxy;
char *info;
+ char *header;
unsigned int retry_sleep;
unsigned int offs;
unsigned int method;
diff --git a/suricatta/server_hawkbit.c b/suricatta/server_hawkbit.c
index 02ffb3a..480750d 100644
--- a/suricatta/server_hawkbit.c
+++ b/suricatta/server_hawkbit.c
@@ -1521,6 +1521,12 @@ static int suricatta_settings(void *elem, void __attribute__ ((__unused__)) *da

GET_FIELD_STRING_RESET(LIBCFG_PARSER, elem, "proxy", tmp);
if (strlen(tmp))
SETSTRING(channel_data_defaults.proxy, tmp);
+ GET_FIELD_STRING_RESET(LIBCFG_PARSER, elem, "token", tmp);
+ if (strlen(tmp)) {

+ char *token_header;
+ if (asprintf(&token_header, "Authorization: TargetToken %s", tmp))
+ SETSTRING(channel_data_defaults.header, token_header);
+ }

return 0;

--
2.14.3

[Stefano Babic]

Hi Diego,

I do not know if this is enough. The configuration file cannot be static
and must be adjusted with the token when this is assigned. Should we not
provide the token as command line parameter, too, like we do for tenant ?

Anyway, the most important thing is how this really works. The token is
generated by Hawkbit the first time a device tries to access or can be
added via the management interface. There should be a mechanism to let
add it to the SWUpdate's configuration.

The token is IMHO a weak security feature with the big drawback that it
must individually set for each device. While certificates are loaded in
a trust of chain and can be stored in factory (and later updated, too),
token is dynamically assigned by the Hawkbit server. This means that a
device should ask for the token and store somewhere for further reuse. I
cannot imagine that token is individually assigned via the management
interface - how does it work with thousands of devices ?

[Diego Rondini]

Hi Stefano,

thanks as always for the quick reply.

Sure, I can add it as command line parameter too.

There are actually two kind of tokens:
- GatewayToken, which is valid for all targets (devices) of a hawkBit tenant
- TargetToken which is unique for a given target

> While certificates are loaded in
> a trust of chain and can be stored in factory (and later updated, too),
> token is dynamically assigned by the Hawkbit server. This means that a
> device should ask for the token and store somewhere for further reuse. I
> cannot imagine that token is individually assigned via the management
> interface - how does it work with thousands of devices ?
>

As I mentioned in an earlier email, anonymous authentication is no
longer the default in hawkBit (while still configurable in the server
startup configuration).
I see GatewayToken and TargetToken as options useful mostly for
development (especially the GatewayToken, even hawkBit docs mentions
that), while the certificates are more suited to production envs, as
you say.

If I understood correctly the work you envision is:
1) add support for both GatewayToken and TargetToken
2) add the ability to specify tokens from command line

I don't think we can solve the problem of supporting thousands of
different tokens as part of SWUpdate itself, so that is something that
needs to be automated separately.

Do you have any concerns about supporting the tokens as development features?

Thanks,

[Stefano Babic]

Hi Diego,

ok, thanks.

Right - and in the Hawkbit's documentation :

"This is of course also handy during development or for testing
purposes. However, we generally recommend to use this token with care as
it allows to act in the name of any device.

It seems to me just to test without changing the token each time.

> - TargetToken which is unique for a given target
>

Right.

>> While certificates are loaded in
>> a trust of chain and can be stored in factory (and later updated, too),
>> token is dynamically assigned by the Hawkbit server. This means that a
>> device should ask for the token and store somewhere for further reuse. I
>> cannot imagine that token is individually assigned via the management
>> interface - how does it work with thousands of devices ?
>>
>
> As I mentioned in an earlier email, anonymous authentication is no
> longer the default in hawkBit (while still configurable in the server
> startup configuration).

ok

> I see GatewayToken and TargetToken as options useful mostly for
> development (especially the GatewayToken, even hawkBit docs mentions
> that), while the certificates are more suited to production envs, as
> you say.

Well, the main goal of whole development is to provide a safe and error
free deployment system for *real* devices. I have no problem to add
features for development, it must just be documented.

>
> If I understood correctly the work you envision is:
> 1) add support for both GatewayToken and TargetToken
> 2) add the ability to specify tokens from command line

The second is helpful if the token can be dynamically read by first
access, but also this helps for testing.

>
> I don't think we can solve the problem of supporting thousands of
> different tokens as part of SWUpdate itself, so that is something that
> needs to be automated separately.

Well, I am trying to understand which is the usage of the token and
which is its added value. I am missing something.

Token is automatically generated by Hawkbit at first access. Let's say,
we use Hawkbit UI and we have not (at the moment) an additional backend
to drive Hawkbit via DMF.

Now the token is in Hawkbit's database, but how does the device know it
? It can work just if the device knows the token from a factory data,
such as it derives the token from an assigned id (serial number, mac
address,...). But this requires to set the token via DMF.

>
> Do you have any concerns about supporting the tokens as development features?

No, it can be added.

Best regards,
Stefano Babic

[Diego Rondini]

Hi Stefano,

sorry for the delayed reply.

Heavy snipping follows, to focus on main topics on discussion.

On Fri, Feb 23, 2018 at 2:25 PM, Stefano Babic <sba...@denx.de> wrote:
> <snip>

>
>> There are actually two kind of tokens:
>> - GatewayToken, which is valid for all targets (devices) of a hawkBit tenant
>
> Right - and in the Hawkbit's documentation :
>
> "This is of course also handy during development or for testing
> purposes. However, we generally recommend to use this token with care as
> it allows to act in the name of any device.
>
> It seems to me just to test without changing the token each time.

Exactly, it's called "gateway" because in this configuration there's
some kind of gateway (can be a piece of software) managing the
communication in the name of the devices.
Nothing prevents multiple different devices to use the same
GatewayToken as a weak shared secret security authentication method.


> <snip>

>
>> I don't think we can solve the problem of supporting thousands of
>> different tokens as part of SWUpdate itself, so that is something that
>> needs to be automated separately.
>
> Well, I am trying to understand which is the usage of the token and
> which is its added value. I am missing something.
>
> Token is automatically generated by Hawkbit at first access.

That's true, but not totally accurate.
TargetToken is generated by hawkBit when a target is created. There
are multiple options to create a target:
https://gitter.im/eclipse/hawkbit/archives/2016/07/27

The easiest way to create multiple targets is to do a "Bulk upload"
with a list of controller IDs in a .csv file.
http://www.eclipse.org/hawkbit/documentation/interfaces/management-ui.html#feature-explained
The targets created that way will immediately get a unique TargetToken.

> Let's say,
> we use Hawkbit UI and we have not (at the moment) an additional backend
> to drive Hawkbit via DMF.
>
> Now the token is in Hawkbit's database, but how does the device know it
> ? It can work just if the device knows the token from a factory data,
> such as it derives the token from an assigned id (serial number, mac
> address,...). But this requires to set the token via DMF.
>

I think the workflow can be something like this:
1) create a list of controller IDs based on some unique property of
the device itself
2) populate a .csv with the aforementioned controller IDs
3) bulk upload the targets on hawkBit using the .csv
4) obtain the TargetToken for each controller ID e.g. using Management API:
https://docs.bosch-iot-rollouts.com/documentation/rest-api/targets-api-guide.html#_response_example
5) flash controller ID and TargetToken to the device (there are
endless possibilities to do this)

The device now has everything needed to successfully connect at first attempt.

>
>>
>> Do you have any concerns about supporting the tokens as development features?
>
> No, it can be added.
>

I will go ahead with this, but it'll take some time proceed due to other duties.

[Stefano Babic]

Hi Diego,

I am just to check all open patches if I am missing something - thread
is quite old, I am just reading that a new version will be sent. Do you
plan to post an update for this ?

Best regards,
Stefano

[Diego Rondini]

Hi Stefano,

On Mon, Apr 16, 2018 at 12:06 PM, Stefano Babic <sba...@denx.de> wrote:
> <snip>
>

> I am just to check all open patches if I am missing something - thread
> is quite old, I am just reading that a new version will be sent. Do you
> plan to post an update for this ?
>

Yes, I do.

However, I'm quite busy so I can't provide a real plan for that.

I hope to find the time to work on that before the end of June. I know
it's quite some time...

Bests,