| Message ID | 20180223100829.10132-1-diego.rondini@kynetics.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [PATCHv2] hawkbit: adding authentication using security token | expand |
Hi Diego, On 23/02/2018 11:08, Diego Rondini wrote: > From: Ayoub Zaki <ayoub.zaki@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.zaki@embexus.com> > Signed-off-by: Diego Rondini <diego.rondini@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"; 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 ? > */ > }; > > 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; > > 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 ? Best regards, Stefano
Hi Stefano, thanks as always for the quick reply. On Fri, Feb 23, 2018 at 1:09 PM, Stefano Babic <sbabic@denx.de> wrote: > Hi Diego, > > On 23/02/2018 11:08, Diego Rondini wrote: >> From: Ayoub Zaki <ayoub.zaki@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.zaki@embexus.com> >> Signed-off-by: Diego Rondini <diego.rondini@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"; > > 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 ? > Sure, I can add it as command line parameter too. >> */ >> }; >> >> 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; >> >> > > > 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. 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, Diego Rondini Sr. Embedded Engineer Kynetics www.kynetics.com
Hi Diego, On 23/02/2018 13:49, Diego Rondini wrote: > Hi Stefano, > > thanks as always for the quick reply. > > On Fri, Feb 23, 2018 at 1:09 PM, Stefano Babic <sbabic@denx.de> wrote: >> Hi Diego, >> >> On 23/02/2018 11:08, Diego Rondini wrote: >>> From: Ayoub Zaki <ayoub.zaki@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.zaki@embexus.com> >>> Signed-off-by: Diego Rondini <diego.rondini@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"; >> >> 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 ? >> > > Sure, I can add it as command line parameter too. ok, thanks. > > >>> */ >>> }; >>> >>> 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; >>> >>> >> >> >> 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. > > 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. > - 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
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 <sbabic@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. Thanks, Diego Rondini Sr. Embedded Engineer Kynetics www.kynetics.com
Hi Diego, On 28/02/2018 17:03, Diego Rondini wrote: > 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 <sbabic@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. > 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
Hi Stefano, On Mon, Apr 16, 2018 at 12:06 PM, Stefano Babic <sbabic@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, Diego Rondini Sr. Embedded Engineer Kynetics www.kynetics.com
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;