In my first post here in this Security blog series, I explained how we do threat analysis and how we map potential security threats to software architecture. With this second post, I would like to share with you a more technical view of security. Get ready to roll your sleeves up for this hands-on session on securing an Internet of Things (IoT) application.
The first thing I would like to introduce is how to secure a document server. Please refer to the following illustration:
Clik here to view.
Access to a content database over an HTTP server from a single-sign-on (SSO) application
In our particular case this server is used to serve specific human readable documents. But it could also be used to gain access to other files such as java script files or specific dlls. So in an IoT context, any client out there could use this infrastructure to get secure access to files on this server. If we are talking about the Internet of Things, each thing would have to log in only once to gain access to the content database.
I’m going to explain this architecture based on our specific solution. In our case the server holds various documents of high economic value, though it is accessible over the internet. For a better understanding, the following background is helpful. Of course, only authorized persons should have access to the document server. Since the whole client application is single–sign-on, there is no option for an additional username-password dialog in order to secure certain documents when loaded from the server. The document from the server is accessed via the client’s software, which already has a username-password authentication mechanism in place. Since the document server is a pure HTTP server (Apache), a web application service is in any case not an option for user authentication.
How best to secure such an architecture? We have realized several security gates. First of all, we put in place basic security for the communication channel by applying SSL. But this is pretty obvious. Additionally, we implemented a special username-password authentication. It is linked to a valid key that is generated within the application – a necessary step, since the content server is agnostic of the user logged in to our client. As a result, a combination of username and key is used for authorization, with the key representing the password. To prevent hijacking of the user’s identity, of course the key is encrypted using a hashing algorithm. Username and hashed key are stored in a separate database – with read access only for the document server. Database access from the document server is done using the mod_authn_dbd module in the Apache server. See the configuration in place:
<Directory ${HTTPD_AUTH_MEDIADIR}>
# core authentication and mod_auth_basic configuration for mod_authn_dbd
AuthType Basic
AuthName "YourName"
AuthBasicProvider dbd
# core authorization configuration
Require valid-user
# mod_authn_dbd SQL query to authenticate a user
AuthDBDUserPWQuery "SELECT PASSWORD FROM TABLE WHERE USER_ID = %s"
</Directory>
The user is specified for database authorization first by using the AuthName parameter, and second by specifying the sql statement to select the hashed key (password) from the database. The username that was passed to the document server is used as a parameter. If the returned key matches the key that was passed to the document server during the request, the user is allowed to download the requested document. For more details about mod_authn_dbd, please visit http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html.
Now it’s your turn:
Which details of realization are you interested in learning more about?