secure apis for applications in microkernel-based systems

Secure APIs For Applications In Microkernel-Based Systems

Mohammad Hamad , and Vassilis PrevelakisInstitute of Computer and Network Engineering, Technical University of Braunschweig,Braunschweig, Germany

{mhamad,prevelakis}@ida.ing.tu-bs.de

Keywords: Security, Secure APIs .

Abstract: The Internet evolved from a collection of computers to today’s agglomeration of all sort of devices (e.g.printers, phones, coffee makers, cameras and so on) a large part of which contain security vulnerabilities. Thecurrent wide scale attacks are, in most cases, simple replays of the original Morris Worm of the mid-80s.The effects of these attacks are equally devastating because they affect huge numbers of connected devices.The reason for this lack of progress is that software developers will keep writing vulnerable software due toproblems associated with the way software is designed and implemented and market realities. So in order tocontain the problem we need effective control of network communications and more specifically, we need tovet all network connections made by an application on the premise that if we can prevent an attacker fromreaching his victim, the attack cannot take place. This paper presents a comprehensive network securityframework, including a well-defined applications programming interface (API) that allows fine-grained andflexible control of network connections. In this way, we can finally instantiate the principles of dynamicnetwork control and protect vulnerable applications from network attacks.

1 INTRODUCTION

Every day we come across examples of securityfailures that cast doubt on the reliability of today’sIT infrastructure. We hear about compromises span-ning huge numbers of IoT devices, or about hundredsof thousands of customer records lost. All these fail-ures largely stem from the ability of Internet-awaredevices (or hosts) to be contacted by any other hostconnected to the Internet. Our lack of effective man-agement of these connections is allowing malfeasantsto connect to our devices and cause havoc. Anotherproblem lies with the applications themselves. Evenwhen extensively tested, they often contain vulnera-bilities that, while extremely difficult to be detectedvia traditional testing, provide the means for attack-ers to compromise the application and potentially takeover the host. Moreover, applications developed usingvastly different development methodologies and qual-ity often coexist in the same environment (e.g. enter-tainment systems in cars coexisting with critical sys-tems such as stability control, steering and breaking)allowing stepping stone attacks.

The need to protect these applications from beingcontacted by random hosts from across the Internethas been well understood since the original Morrisworm of the mid-80s. Unfortunately, the solutions

proposed proved inadequate and in some cases exac-erbated the problem. For example firewalls have theability to guard the entrances of networks and allowonly ”good” guys to connect to internal hosts. Ini-tially, firewalls proved quite effective, but over theyears, they gradually became irrelevant (Niederbergeret al., 2006) as WiFi connections allowed firewallsto be bypassed and Transport Layer Security (TLS)(Dierks and Rescorla, 2008) ensured that traffic flow-ing via these firewalls is encrypted so that they areincapable of monitoring it for attacks.

In a typical banking application scenario, the cus-tomer uses TLS to connect to the banking applicationrunning on the banks servers (Hiltgen et al., 2006).The connection is cleared by the firewall before thecustomer is identified by the system. This is so be-cause identification is handled by the application af-ter the TLS session has been established. Thus, notonly we are forcing the firewall to allow all connec-tions from the public Internet to our application, butwe also prevent any network-based intrusion detec-tion system from monitoring the data exchanged overthe encrypted connection.

It is thus crucial for the connection request to bevetted before it is allowed to reach the application.The problem with the traditional way of controllingaccess to the application, is that it involves a lot of

https://doi.org/10.24355/dbbs.084-201806251531-0

manual configurations (e.g. configuring packet filtersetc.), requires administrator access and is, thus, ex-pensive, slow and error prone. We, therefore, need afaster, automated way for access control. We proposeto de-couple the access control mechanism from thenetwork code and use a policy engine to evaluate re-quests if authorized, and to reconfigure the system ac-cordingly. In this way we can accommodate dynamicscenarios such as load balancing or failure recovery.

Our mechanism should also allow interactions be-tween applications running in distributed control sys-tems such as those found in vehicles, airliners, etc.Numerous hacking demonstrations on car ECUs haveshown that once access to the internal communica-tion bus is gained by the attacker, then the entire ve-hicle is compromised (Koscher et al., 2010). Tradi-tional approaches have proven to be too inflexible forcomplex distributed environments so we had to lookfor a better solution based on the distributed firewallmodel proposed by Ioannidis et al (Ioannidis et al.,2000). Under this framework each connection re-quest must include appropriate authentication and au-thorization to allow both the sending and receivinghosts to decide whether to allow the connection re-quest to go through. In this way, there is no need topre-configure the elements of the distributed systemwith access control information, but the communica-tions policy is dynamically constructed as communi-cations requests are made and granted. Eventually wewill have a set of secure links connecting applicationsrunning on different hosts, but unlike the static con-figuration model, new requests can be accommodatedand integrated into the overall system policy.

Any distributed security paradigm will eventuallyfail unless it can be used by the application develop-ers. By providing a proper security application-layerdevelopers will be able to implement applications thatuse secure communications efficiently. Moreover,this layer will make it more convenient and applicablefor protecting the application communications.

In this paper, we present new APIs that give anyapplication the power to control its security policyby providing sufficient configurations to the securitylayer. This enables an application to get the relevantinformation about the applied security mechanismsand all the parameters of the secure channel. We alsoprovide APIs which allow any application to authen-ticate the requesters identity and indicate whether thisrequest is authorized or not based on the security pol-icy of the receiving application. The authorization de-cision will not be based on packet filtering and Ac-cess Control Lists (ACLs) mechanisms. We use theKeynote trust management (Blaze et al., 1999) modelto enable the application to determine the allowed net-

work access regarding credentials presented by the re-mote application, which should conform to the localpolicy of the application.

The rest of the paper is organized as follow. InSection 2, we provide a short background and somerelated works. Section 3 explains the design of the se-cure APIs. The implementation of APIs is detailed inSection 4. In Section 5, we discuss some evaluationasspects. Finally, Section 6, contains some conclud-ing remarks.

2 BACKGROUND AND RELATEDWORK

Many mechanisms and protocols were defined toprotect sensitive and critical system resources. TLSis one of these techniques which is used to securecommunications at the application layer. It uses en-cryption and authentication to keep communicationsprivate between two devices; typically a web server(website) and a browser. TLS is limited to TCP andSTCP based protocols. An adaptation of TLS forUDP protocol is available; it is called DTLS. How-ever, it is not widely used. Numerous modificationson the application’s source code are required to run itover TLS. In some circumstances, these changes im-pose significant complexity overhead.

Another important mechanism is Internet Proto-col Security (IPsec) (Kent and Seo, 2005). It was de-signed to provide network security services to protectInternet datagrams. It provides its security servicesover two protocols: the first one is called Authentica-tion Header (AH) (Kent and Atkinson, 1998a) whichprovides origin authentication, data integrity and op-tional replay attack protection. The second protocolis called Encapsulating Security Payload (ESP) (Kentand Atkinson, 1998b) which provides the confiden-tiality and authentication of the exchanged data. Al-though IPsec was introduced a few years ago, its us-age was confined to VPN implementation. The lackof APIs was one of the main reasons that limited theadoption of the IPsec to provide end-to-end security(Bellovin, 2009), (Ioannidis, 2003). Without theseAPIs, applications were not able to interact with theIPsec layer and verify whether IPsec services are be-ing used underneath. The requirements of an applica-tion to interact with security layer were specified byRichardson and et al. (Richardson and Sommerfeld,2006). They claimed that each application should beable to:

1. Determine HOW a communication was protected,

2. Identify WHO is the remote party,


3. Influence HOW the protection should take place,and

4. Indicate WHY an authorized communicationfailed.

All these requirements should be carried out as a setof APIs which could be used by the applications.

McDonald (McDonald, 1997) first proposed theimplementation of such APIs. He introduced the con-cept of IPsec API as an extension to the BSD Socketswhere applications could provide their configurationper socket. Wu et al. (Wu et al., 2001) providedan API which gives the application the capability tochoose the IPsec tunnel which will be used to protectoutgoing packets. It also enables the application toknow which tunnel was used to receive a particularincoming packet. Information are extracted from theIPsec header, associated with the received data andthen delivered to the application regarding the usedprotocol (TCP, UDP). However, their APIs did notmanage the creation of the IPsec tunnels by the ap-plication.

According to Arkko et al. (Arkko and Nikander,2003), the lack of APIs is not the only problem inthe IPsec design. The current security policy mecha-nism is another stumbling block the adoption of IPsecfaces, in the end to end application-level protection.

Yin and Wang in (Yin and Wang, 2007) suggesteda solution fix for the lack of the IPsec policy sys-tem by introducing a mechanism that makes applica-tions aware of the IPsec policy. They implementeda socket manager which detects the sockets’ activ-ities of the running application and report them tothe application policy engine. The engine gets theapplication policies, which are stored in the policyrepository. It processes them and then writes fine-grained policies into the Security Policy Database(SPD). In their work, they did not change the exist-ing IPsec/IKE infrastructure. They kept using hostauthentication rather than application-based authenti-cation which is required to secure application commu-nications. Pereira et al. (Pereira and Beaulieu, 1999)tried to provide a user-based authentication schemwithin the IKE implementation by introducing new aexchange phase, which was called phase 1.5. Withinthis invented phase, challenge-response messages areexchanged between the remote user and the securitygateway.

3 DESIGN

Although IPsec’s application-agnostic design is anadvantage, in the sense that IPsec can protect applica-tions without any modification to their source code, it

Application

Sec_API

Active Policy

Decision

Trust Management

System

KeyNote

socket call verify add, delete, search

Global Policy

Application

Credentials

Application

Application Credentials

Application

Network Stack

Application Credentials

Figure 1: Application interactions using the secure API tointeract with the trust management system and the securitylayer in the network stack (i.e. IPsec)

Authorizer: Trusted_Public_key

Licensees: App_Public_key

Conditions: ( Src_ip_address ==ANY&& Dst_device_name == My IP&& Src_port == ANY && Dst_port == ( 80 || SSL PORT) && Security_level >= SL_INTEGRITY && Priority_level == HIGH -> “ALLOW“

Signature: Trusted_Private_key

Figure 2: An example of a security credential which wasgiven to an application

is also a disadvantage because (a) the application cannot request a secure connection, (b) it can not spec-ify parameters of the secure connection, (c) and it cannot verify whether its connection is secure or not. Inthis work, we try to handle some of the obstacles byproviding suitable APIs which enable the applicationto so.

3.1 Overriding The Security Policy

Using static security policies is one of the main draw-backs of the existing security implementation. Forexample, SPD selectors which are used with IPsecshould be specified in advance. These selectors con-tain the IP addresses and port numbers. In some cir-cumstances, some selectors are not available in ad-vance, such as the port number is not always static forsome protocols. Consequently, such selectors are leftempty in the IPsec security policy. Later, when twodifferent applications on the same host with differentport numbers, try to connect to the same remote ap-plication, there will be no distinguishable selectors to


differentiate their two separate connections. Thus, theneed of dynamic management for the IPsec policy iscritical.

Supplying the application with the ability to de-fine the security policies might solve such a problem.Each application should be authorized to set up andupdate its security policy which fulfills its require-ments dynamically. Authorization is required to pre-vent the application from tampering with the secu-rity policy parameters which belong to different ap-plications. The decision whether the application ad-mitted setting the security policy is made by the trustmanagement system. The trust management system,shown in Figure 1, contains KeyNote engine whichevaluates the potential action of each application. Therequest should be consistent with the global systempolicy, to be authorized. The global system policyrepresents the least accepted security parameters andsystem-wide security configuration. Each applicationhas communication credentials, as shown in Figure 2,which assure the ability to initiate an authorized con-nection as long as it does not conflict with the globalpolicy. Dynamic management will ensure interdepen-dence between the policy rule and the connection’scharacteristics. To deal with the dynamic port num-ber problem, we bind each application’s connectionto a port from the static ports pool. In the same way,if the IP address is left empty in the application pol-icy, it will be assigned to the host IP address. Whenan application would like to set up a connection with aremote one by Sec bind, Sec connect, Sec sendto, orSec recvfrom it will provide its security context whichcontains attributes of the proposed action as shown inTable 1.

All the proposed functions are using the same pa-rameters of the comparable Socket functions, besidestheir credentials and the security context:

int Sec_connect(connect() parameters,char* credential,security_context* sec_cont)int Sec_bind(bind() parameters,char* credential,security_context* sec_cont)int Sec_sendto(sendto() parameters,char* credential,security_context* sec_cont)int Sec_recvfrom(recvfrom() parameters,char* credential,security_context* sec_cont)

Security context and the credential (it could be chainof credentials) are, all together, delivered to the trustmanagement system which will check whether an ap-plication is authorized to set up such a connection ornot. It will determine whether the proposed action iscompliant with the global policy by applying the secu-rity context parameter to the credential’s conditions.In the case of an authorized request, a new securityrule will be added to the SPD. In addition to that, areference from this rule will be stored in the protocolcontrol blocks (PCBs) structure associated with the

socket. This reference will be used later to delete thisrule when the application closes the connections (i.e.Sec close).

int Sec_close{socket s )

3.2 Interacting With Security Layer

By placing the IPsec mechanisms in the networklayer, the designer created an abstraction layer thatdecouples the applications from the security of itscommunications. In other words, the applicationscannot easily determine the identity of their commu-nicating parties or the characteristics of the securityselected on the communication link. By contrast, ifthe applications use TLS, it can both authenticate theirremote party and specify the form of encryption usedfor the communication.

Providing sufficient APIs, which enable the appli-cation to interact with the IPsec layer, will increasethe application comprehension about the used secu-rity mechanisms in the ground layers. The proposedAPIs enable any application to determine if an incom-ing communication is protected or not. In the caseof protection, it grants an application the right to re-trieve the security properties which were used to pro-tect the data. These security properties could containthe cryptographic algorithms which were used, thelength of the key, the type of security service (con-fidentiality, or integrity) etc. Each application will beauthorized to get the security parameters which relateto its connection. The default security settings, whichis defined in the global policy, are available to any ap-plication.

The Sec getsockopt and Sec setsockopt systemcalls manipulate the options associated with a socket.Table 2 describes the security services which couldbe used : Each of the options presented in Table 2 canhave different security levels associated with it (i.e.SEC NONE, SEC BYBASS, SEC USE, etc.). Therelevant information (security levels, security service,etc.) is stored in PCB’s structure associated with thesocket.

int Sec_getsockopt(socket s, Sec_service srv,Sec_level lvl, void *optval,int *optlen)int Sec_setsockopt(socket s, Sec_service srv,Sec_level lvl, void *optval,int *optlen))

3.3 Providing The Ability OfAuthorization and Authentication

The existing certificate authority does not assure thetrustworthiness of the key owner, but merely authen-ticates the owner’s identity. However, we are not onlyinterested in identifying the remote part. We need a


Table 1: Security Context Fields.

Field DescriptionPorts numbers Port numbers which application listens to and the remote port number (it can be any)IP addresses IP address used by the application and the remote IP (it can be any)Issued Time Time when the request was issued, it is used to prevent replay attacks

Others Another security properties such as encryption algorithm, level of security, etc.Signature Requester application signs all the previous fields with its private key

Table 2: Security Services.

SEC AUTH Refers to the use of authentication for the connectionSEC CON Refers to the use of encryption for the connection

SEC AUTH CON Refers to the utilization of both authentication and encryption

mechanism that tells us the allowed actions that theremote part is able to perform . The certificate in-frastructure does not handle the decisions whether theremote party is allowed to access services or not. Thisdecision is left up to the application.

Within the proposed APIs layer, we give the appli-cation the ability to authenticate and decide whetherthe remote peer is authorized to do some actions de-pending on its credentials and the local policy in aneasy manner. In other words, we combine the authen-tication with access control. The application is able toget the remote party’s identity and credentials.

int Sec_getremoteCredentials(socket s,char * credentials)

int Sec_getremoteKey(socket s, char * key)

4 IMPLEMENTATION

We started our implementation by providing a setof APIs which function on the socket layer of the net-work stack and interact with the IPsec layer. Practi-cally, in the monolithic operating systems (OS), suchas Linux and Windows, IPsec and the network stackare implemented in the kernel; this limits our ability todevelop our APIs. On the other hand, Within Micro-kernel OS, IPsec, which is integrated into the TCP/IPstack, is implemented in the user space. This gaveuse more scalability and functionality to implementthe required APIs. Thus, we implemented our APIson a Raspberry PI computer running a MicrokernelOS; we used Genode OS (Genode Labs GmbH, ).

We used an existing embedded IPsec infrastruc-ture, which was implemented on Genode OS byHamad et.al (Hamad and Prevelakis, 2015), to deve-lope our security APIs. For the policy framework,we used a framework that was proposed by Preve-lakis et.al (Prevelakis and Hamad, 2015) to providea mechanism to maintain the integrity of the appli-

cations credentials and enforce them during the run-time phase. Keynote library was ported to Genode OSwhich was used to evaluate the applications requests.We implemented many APIs to provide the intractionbetween the trust managment system and the activepolicy repository (as shown in hown in Figure 1).

5 EVALUATION

Security has a price; it is clear that using our APIsimposes some overhead. Such overhead comes frompolicy evaluation, credential verification and provid-ing security services (i.e. IPsec). From the various se-curity overheads, we have found in (Hamad and Pre-velakis, 2015) that the operational security overheadof security services is very low after the configurationis over.

In the other hand, the overhead of evaluating thecredentials and the operation of the policy engine issignificant, but it occurs only when a new connectionrequest must be considered (i.e. it is compliant withthe policy). Hence, the cost must be amortized overthe lifetime of the connection. In vehicular platforms,connections tend to have a long lifetime. So, this par-ticular overhead is not significant. Moreover, variousoptimization techniques, such as caching verified cre-dentials and policy, may be used to reduce the cost ofpolicy evaluation.

6 CONCLUSIONS

Providing the proper security application-layercan increase the ability of applications to use securecommunication efficiently. In the same time, it willmake it more convenient and applicable for protect-ing the application communications.

In this paper, we implement new APIs which giveany application the ability to control its security pol-


icy by providing sufficient configurations to the se-curity layer. Moreover, it enables an application toget the relevant information about the applied secu-rity mechanisms and all the parameters of the securechannel. We also provide APIs which allow any ap-plication to authenticate the requester’s identity andindicate whether this request is authorized or not,based on the security policy of the receiving appli-cation. The authorization decisions are not based onpacket-filter and ACLs mechanisms.

Adoption of our secure APIs by applicationscaused a performance overhead. However, our im-plementation is still in a proof-of-concept stage; dif-ferent optimization methods could be used to reducethis overhead.

7 ACKNOWLEDGEMENT

This work was supported by the DFG ResearchUnit Controlling Concurrent Change (CCC), fundingnumber FOR 1800. We thank the members of CCCfor their support

REFERENCES

Arkko, J. and Nikander, P. (2003). Limitations of ipsec pol-icy mechanisms. In Security Protocols, 11th Inter-national Workshop, Cambridge, UK, April 2-4, 2003,Revised Selected Papers, pages 241–251.

Bellovin, S. (2009). Guidelines for specifying the use ofipsec version 2. BCP 146, RFC Editor.

Blaze, M., Feigenbaum, J., Ioannidis, J., and Keromytis,A. D. (1999). The keynote trust-management systemversion 2. RFC 2704, RFC Editor.

Dierks, T. and Rescorla, E. (2008). The Transport LayerSecurity (TLS) Protocol Version 1.2. RFC 5246 (Pro-posed Standard).

Genode Labs GmbH. Genode OS Framework. https://genode.org/ [last access on Jan 2017].

Hamad, M. and Prevelakis, V. (2015). Implementation andperformance evaluation of embedded ipsec in micro-kernel os. In Computer Networks and Information Se-curity (WSCNIS), 2015 World Symposium on, pages1–7. IEEE.

Hiltgen, A., Kramp, T., and Weigold, T. (2006). Secureinternet banking authentication. IEEE Security & Pri-vacy, 4(2):21–29.

Ioannidis, J. (2003). Why don’t we still have ipsec, dammit?In NDSS 2003.

Ioannidis, S., Keromytis, A. D., Bellovin, S. M., and Smith,J. M. (2000). Implementing a distributed firewall. InProceedings of the 7th ACM conference on Computerand communications security, pages 190–199. ACM.

Kent, S. and Atkinson, R. (1998a). Ip authentication header.RFC 2402, RFC Editor.

Kent, S. and Atkinson, R. (1998b). Ip encapsulating secu-rity payload (esp). RFC 2406, RFC Editor.

Kent, S. and Seo, K. (2005). Security Architecture for theInternet Protocol.

Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno,T., Checkoway, S., McCoy, D., Kantor, B., Anderson,D., Shacham, H., et al. (2010). Experimental secu-rity analysis of a modern automobile. In 2010 IEEESymposium on Security and Privacy, pages 447–462.IEEE.

McDonald, D. L. (1997). A Simple IP Security API Exten-sion to BSD Sockets. Internet-Draft draft-mcdonald-simple-ipsec-api-02, Internet Engineering Task Force.

Niederberger, R., Allcock, W., Gommans, L., Grunter, E.,Metsch, T., Monga, I., Valpato, G. L., and Grimm, C.(2006). Firewall issues overview.

Pereira, R. and Beaulieu, S. (1999). Extended Authenti-cation Within ISAKMP/Oakley (XAUTH). Internet-Draft draft-ietf-ipsec-isakmp-xauth-06, Internet Engi-neering Task Force. Work in Progress.

Prevelakis, V. and Hamad, M. (2015). A policy-based com-munications architecture for vehicles. In InternationalConference on Information Systems Security and Pri-vacy, France.

Richardson, M. and Sommerfeld, B. E. (2006). Require-ments for an IPsec API. Internet-Draft draft-ietf-btns-ipsec-apireq-00, Internet Engineering Task Force.

Wu, C.-L., Wu, S. F., and Narayan, R. (2001). Ipsec/phil(packet header information list): design, implementa-tion, and evaluation. In Li, J. J., Luijten, R. P., andPark, E. K., editors, ICCCN, pages 206–211. IEEE.

Yin, H. and Wang, H. (2007). Building an application-aware ipsec policy system. IEEE/ACM Transactionson Networking, 15(6):1502–1513.


secure apis for applications in microkernel-based systems

Documents