Yongzheng Wu
email: wu.yongzheng@huawei.com

Roland H C Yap
email: ryap@comp.nus.edu.sg

Simple and Practical Integrity Models for Binaries and Files

Software environments typically depend on implicit sharing of binaries where binaries are created, loaded/executed and updated dynamically which we call the binary lifecycle. Windows is one example where many attacks exploit vulnerabilities in the binary lifecycle of software. In this paper, we propose a family of binary integrity models with a simple and easy to use trust model, to help protect against such attacks. We implement a prototype in Windows which protects against a variety of common binary attacks. Our models are easy to use while maintaining existing software compatibility, i.e. work with the implicit binary lifecycle requirements of the software and assumptions on binary sharing. We also propose a conservative extension to protect critical non-binary files.

Introduction

It is typical in software environments that the software consists of a collection of software components in the form binaries such as executables, dynamically linked libraries (DLLs), plugins, drivers, etc., e.g. this is the case in Windows. Binaries may be shared and used (executed/loaded) by many software, e.g. Windows Office software components are shared by programs in the Office suite. Binaries are usually created when a software is installed. Software updates modify/delete existing binaries or create new ones. Software uninstall usually deletes binaries. We call the creation, usage, sharing, modification and deletion of binaries associated with software, the lifecycle of binaries.

Binaries often have a complex and dynamic lifecycle with many kinds of interactions (arising from functionality, usability and software development reasons). However, the binary lifecycle is also exploited in attacks, e.g. a Java malware (EUR:Backdoor.Java.Agent.a [START_REF]HEUR:Backdoor.Java.Agent[END_REF]) exploits a vulnerability (CVE-2013-2465) to copy itself to the user home directory and launch on system startup. This attack shows exploitation of the binary lifecycle in two ways: (a) it uses operating system mechanisms which can load or execute binaries; and (b) the malware uses binaries so that it becomes persistent.

Windows is a primary target for binary attacks. It has mostly implicit sharing of binaries and co-dependencies between binaries, e.g. Firefox uses other software plugins, Windows Explorer uses third party codecs, etc. Windows also has a large attack surface [START_REF] Dai | Understanding Complex Binary Loading Behaviors[END_REF][START_REF] Howard | Measuring Relative Attack Surfaces, Workshop on Advanced Developments in Software and Systems Security[END_REF] with many mechanisms for running executables or loading binaries which is used both in the binary lifecycle but also exploited in attacks.

Many security models and mechanisms [START_REF] Badger | Practical domain and type enforcement for UNIX[END_REF][START_REF] Biba | Integrity Considerations for Secure Computer Systems[END_REF][START_REF] Halim | A Lightweight Binary Authentication System for Windows[END_REF][START_REF] Kato | SoftwarePot: an Encapsulated Transferable File System for Secure Software Circulation[END_REF][START_REF] Liang | Alcatraz: An Isolated Environment for Experimenting with Untrusted Software[END_REF][START_REF] Wurster | Self-Signed Executables: Restricting Replacement of Program Binaries by Malware[END_REF] have been proposed to protect against binary attacks. They may not be practical in a Windows context and mostly not designed for a dynamic and closed-source binary lifecycle. Furthermore, policy-based mechanisms may be less practical as it assumes users can create and maintain complex policies. This is not realistic in commodity operating systems like Windows. Thus, a good tradeoff between security and usability is needed.

Our goal is to increase security in the binary lifecycle. We propose and formalize a family of security models, BInt, which provides binary integrity and protection by incorporating an easy-to-use trust labelling mechanism. We also propose FInt which extends to protecting other critical files. We apply BInt by implementing a Windows prototype which protects against common binary attacks while giving good compatibility with existing software and deals with binary lifecycle issues. It is fairly easy to use without the need for complex administration or policy specification.

Related Work

The Biba model [START_REF] Biba | Integrity Considerations for Secure Computer Systems[END_REF], is an early security policy to secure information flows. Data integrity is achieved by preventing information flow from low to higher levels (labels). However, Biba style models are not suitable for the binary lifecycle problem and it is unclear whether binaries are data or subjects.

Domain and Type Enforcement (DTE) [START_REF] Badger | Practical domain and type enforcement for UNIX[END_REF] is representative of MAC access control approaches where a policy specifies what access is allowed by domains (states of processes) and types (resources). DTE and also other policy based approaches, e.g. Biba, have usability challenges -how to create and maintain policies dealing with the binary lifecycle given that the software and lifecycle details may be unknown and not under one's control, e.g. Windows.

Signed binaries only allow signed binaries to be loaded or executed [START_REF] Apvrille | DigSig: Run-time Authentication of Binaries at Kernel Level[END_REF][START_REF] Halim | A Lightweight Binary Authentication System for Windows[END_REF]] However, signing is primarily about establishing trust relationships. It only ensures that the signed binaries are from a party having the key. Requiring all software to be signed is best under a closed ecosystem, e.g. iOS, but less practical in an open ecosystem like Windows.

The Windows binary lifecycle also requires updates -creating new problems for trust management. The security of signing is based on trusting the signing keys, e.g. the Stuxnet worm has a driver signed by a Realtek key, thus, is implicitly trusted by Windows. Revocation checking is expensive as it cannot be done locally and may not be timely. Bit9 [3] a binary whitelisting system was attacked to compromise systems protected by Bit9 signatures [2].

Self-signed executables [START_REF] Wurster | Self-Signed Executables: Restricting Replacement of Program Binaries by Malware[END_REF] is proposed for easier management of software updates for signed binaries. While it protects binary integrity for updates, it does not prevent new malware from being introduced. Deletions cause a problem -the file stubs increasing monotonically over time. It also modifies the normal POSIX file semantics which may break compatibility.

Isolation lets untrusted programs read the trusted system while confining the modifications [START_REF] Kato | SoftwarePot: an Encapsulated Transferable File System for Secure Software Circulation[END_REF][START_REF] Liang | Alcatraz: An Isolated Environment for Experimenting with Untrusted Software[END_REF]. Some processes can be executed in isolation domains while others are executed normally in the base system. This may not be practical in the binary lifecycle for software on Windows and the implicit "all" sharing.

While these works provide integrity or restrict binary usage, they are less suited for complex, dynamic and closed-source binary lifecycle environments.

BInt Integrity Models

When a program executes, typically, it runs a binary (the executable) which may load other binaries implicitly (dynamic loading of binaries) or explicitly load binaries during execution. We want to protect "unwanted" binaries from being executed or loaded, i.e. protect against the large binary attack surface of Windows [START_REF] Dai | Understanding Complex Binary Loading Behaviors[END_REF][START_REF] Howard | Measuring Relative Attack Surfaces, Workshop on Advanced Developments in Software and Systems Security[END_REF][START_REF] Wu | Comprehending Module Dependencies and Sharing[END_REF]. In the binary lifecycle of software, binaries are loaded/created/modified/deleted. Securing binaries requires preventing arbitrary modification/deletion of binaries while allowing some software in the lifecycle to do so.

An important consideration is that many security mechanisms rely on explicit policy specification, e.g. Biba [START_REF] Biba | Integrity Considerations for Secure Computer Systems[END_REF] or DTE [START_REF] Badger | Practical domain and type enforcement for UNIX[END_REF] assume someone creates and maintains the policy. In practice, this assumption may not be workableusers cannot be expected to deal with complex policies. The software environment is often dynamic. Users expect to be able to install, update and uninstall (arbitrary) software (within limits). Software updates and auto-updates must be handled. With closed-source software, the workings of the dynamic lifecycle is not known making policies requiring such details problematic. In practice, an implicit requirement is also compatibility with existing software and its lifecycle.

We propose BInt (Binary INTegrity) which is a family of security models for binary usage and integrity to protect against attacks on the binary lifecycle which takes into account the above considerations. 3 The following examples illustrate the problems BInt models handle. In the Safari Carpetbomb attack [8]: the Safari browser automatically downloaded files onto the user desktop, while Internet Explorer by default allowed DLLs to be loaded by filename instead of a full path. A malicious website can then perform a "binary planting attack" [7] where Safari downloads a malicious DLL which Internet Explorer loads. However, running or loading binaries from the desktop is normal behavior in Windows, preventing this also breaks normal functionality. In the PDF embedded executable attack [5], a malicious PDF file contains an embedded executable, viewing the PDF 1. The BInt Model (R1-14) and BInt+tr (R8tr∨, 11tr∨, 8tr∧, 11tr∧) where T (f ) means f is signed by the trusted signature repositories.

p create f d-mode true L d (f ) := ⊥ 1 t-mode true L d (f ) := ⊥ 2 i-mode true L d (f ) := L d (p) 3 p read f true 4 p write or delete f d-mode L d (f ) = ⊥ 5 t-mode L d (f ) = ⊥ 6 i-mode L d (f ) = ⊥∨ L d (f ) = L d (p) L d (f ) := L d (p) 7 p load f d-mode L d (f ) = ⊥ 8 t-
p load f d-mode L d (f ) = ⊥ ∨ T (f ) 8tr∨ p execute f d-mode L d (f ) = ⊥ ∨ T (f ) Lm(p ) := d-mode 11tr∨ p load f d-mode L d (f ) = ⊥ ∧ T (f ) 8tr∧ p execute f d-mode L d (f ) = ⊥ ∧ T (f ) Lm(p ) := d-mode 11tr∧ Table
runs Javascript to write out an executable which can be run from the PDF. However, a legitimate installer also behaves in this fashion.

We start with a basic BInt model using the following abstractions. We denote in an operating system, the following system entities: processes by p and files by f . Each process and file has associated security labels which represent information associated with the process/file -the notation L(o) denotes the security label of the system entity o. 4Processes interact with files and other processes through the actions: create, read, write, delete, execute, and load a file. The load action denotes that a process loads a binary file to be used as a DLL. For Windows, we can use our abstraction to model process creation as follows: a process p executes a binary to create a new process p .

BInt uses two kinds of labels, L m and L d . A process has a state which we call an execution mode. The execution mode label of process p is denoted by L m (p) which can take three values: d-mode (default mode); i-mode (install mode); or t-mode (temporary trusted mode). Intuitively, d-mode corresponds to the normal (default) execution mode for running software and processes start in d-mode.

Installing/updating software occurs in i-mode. For special cases, t-mode handles scenarios when we want to run software which needs to dynamically create and load binaries but is not meant to be software installation, e.g. building binaries in an IDE or for dynamic temporary binaries created by a process.

The second kind of label on a process p or file f , denoted by L d (p) or L d (f ) respectively, can be thought of as a software domain. Intuitively, a particular software domain labels all the processes and files related to a particular installed software. For example, the software domain could denote the name of a particular software or the software vendor. There is a distinguished software domain ⊥ denoting binaries which do not have a valid software domain, we call such binaries b-invalid, otherwise a binary is b-valid. The only relation among software domains is equality (=).

Our first BInt model is formalized in rules 1-14 from Table 1. Each rule specifies the requirement and result of an operation on binaries for a given mode. An actual implementation would distinguish binary files from other files (see Sec. 3) but we omit binary tests to avoid cluttering up the model. Throughout the paper, for brevity, we refer to rule i as Ri.

A b-valid binary can only be created in i-mode with the software domain of the process creating the binary (R3), otherwise only b-invalid binaries are created (R1-2). File reads are not affected by BInt (R4). This helps compatibility. Rules R5-7 deal with binary integrity. To ensure binary integrity, a binary can only be written to or deleted in i-mode if it is b-valid with the same software domain or if it is b-invalid (R7). The integrity of b-invalid binaries is not maintained, so there are no restrictions in d/t-mode as long as it is b-invalid (R5-6).

Rules R8-13 deal with the use of binaries (load/execute). In d-mode, only b-valid binaries can be loaded/executed (R8,11). In t-mode and i-mode, any binary can be loaded (R9, 10) and executed. In our abstraction (as in Windows), executing a binary creates a new process. The execution mode of process p is preserved in the new process p (R11-13) and in i-mode, the software domain of p carries to p (R13).

A process changes its execution mode from d-mode to either i-mode or tmode through a special operation, called modetrans. Changing d-mode to i-mode changes both the mode and software domain of the process, while changing to t-mode only changes L m (p) as the domain is not used (R14). Modetrans is a privileged operation, for example, it could be implemented with a secure authentication mechanism requiring a password to the operating system. Sudo in Unix or UAC in Windows also require secure authentication but they elevate privileges which modetrans does not.

Unlike policies where labels are explicitly specified, our labels on processes and files are implicit. In d-mode and t-mode, file labels are implicitly created as ⊥ and its process label is not relevant. Modetrans allows d-mode to go into i-mode. When switching to i-mode, a label is specified which is the software domain used to label the process. File labels in i-mode come from the software domain obtained from modetrans. In terms of user interaction, the user only specifies the software domain once when performing the privileged modetrans operation.

Modetrans can be thought of as a simple way of associating trust relationships between binaries and its label where the labelling is automatic using just the software domain label from the d-mode to i-mode transition.

Installing and updating software in i-mode assumes that the installer/updater process(es) are part of the process tree hierarchy from the original process in imode for that software domain. While this is reasonable for a generic model, it needs to be customized for a particular operating system -in Windows, we handle the Windows MSI installer and provide an execution mode policy for auto-updaters (see Sec. 3).

Using BInt

We use a life-cycle of the Firefox web browser to illustrate how BInt works. The user first downloads the Firefox installer (f installer ) using some other web browser or downloader (p downloader ), which runs in d-mode (L m (p downloader ) = d-mode). By R1, L d (f installer ) = ⊥. The user then uses the privileged modetrans operation to run the installer in i-mode specifying its software domain as firefox. The installer process (p installer ) and its child processes run in i-mode with the firefox domain, L m (p installer ) = i-mode ∧L d (p installer ) = firefox. The installer installs a number of binaries, which are in the firefox domain according to R3. After installation finishes, the user executes Firefox from the Windows start menu or desktop shortcut. At this point, the Firefox process runs in d-mode due to R11.5 Suppose that Firefox is exploited by a malicious website, e.g. a drive-by-download downloads and runs a malicious executable (f mal ). However, the binary f mal has L d (f mal ) = ⊥ by R1, thus, f mal cannot execute by R11 and the attack fails.

In order for Firefox's auto-update to work, the updater is specified in the execution mode policy (see Sec. 3) so that it automatically runs in i-mode with firefox domain. To uninstall, the user uses modetrans to execute the uninstaller, which then deletes the Firefox binaries without affecting other binaries by R7.

A different scenario occurs during software development -the programmer is often creating binaries which may be transient. The IDE can be run in t-mode allowing the software developed to be temporarily executed (R9, R12).

BInt+tr: Adding Further Trust

BInt focuses on maintaining integrity of binary files. Which binaries to trust is an orthogonal issue. In accordance with defence in depth, we extend BInt with an additional source of trust. We assume an external trusted signature repository publishing signatures of vetted binaries, e.g. such as Bit9 [3], but alternative mechanisms are also possible. The binary signature is used (additionally) to certify that a binary and associated software domain is trusted.

We describe two alternative models, BInt+tr∨ and BInt+tr∧ presented in Table 1 from R8 tr∨ to R11 tr∧ . BInt+tr∨ is a more permissive model which allows binary f to be loaded/executed in d-mode if f is b-valid or if it is certified by the trusted signature repository (R8 tr∨ ,11 tr∨ ). For example, third parties can certify a list of trusted software, a user can use the list to avoid switching to imode to install software in the list. This allows for broader software compatibility without compromising the integrity of other binaries. It also reduces the use of i-mode but requires a trusted service.

A restrictive policy is BInt+tr∧ which requires both signature verification and b-validity (R8 tr∧ ,11 tr∧ ). For example, in an organization, this can enforce that only specified software can be used and exceptions only occur through tmode. Variations of the signing requirements for t-mode are also possible. The whitelist approach of BInt+tr∧ may be too restrictive for general use since only binaries on the whitelist can be executed. A practical incarnation may only require the verification for certain pathnames of software domains. Incorporating an external trust mechanism allows to add MAC policies and also an ecosystem of security providers which provide whitelists of vetted binaries, e.g. similar to Bit9 [3].

An even more restrictive form of BInt+tr∧ is to require that binaries created in i-mode must pass the signature verification, otherwise, the creation and subsequent writing of the binary has no effect. 6 We call this variant, BInt+tr∧W.

Analysis of BInt Models

The binary protection from BInt arises in three ways. First is whether execution or loading of binaries is prevented. Note that this does not prevent all malware code execution, e.g. code injection, we focus on attacks employing binary mechanisms. Second is it provides integrity guarantees for binaries, preventing malware from modifying binaries. Thirdly, in order for malware to persist on the system, it will normally need to be in files (binaries), otherwise the vulnerability must be one which can reoccur on the same system which we do not deal with. 7 We remark that without tailoring BInt for a particular operating system, execution/loading/reading/writing of binaries are the only relevant operations in our model when dealing with binary files so the discussion focuses on these operations and also modetrans. Security of d-mode: Most processes run in d-mode, thus its security is critical. The threat model is whether a process in d-mode can execute/load an undesired binary (b-invalid binary) or modify existing (b-valid) binaries.

The guarantees in d-mode are: b-invalid binaries cannot be loaded (R8); b-valid binaries cannot be modified (R5); and binaries created are b-invalid (R1). Thus, a d-mode process is unable to introduce new binaries to d-mode processes including itself which prevents common attacks which use execution or binary loading. This prevents both the example attacks (Safari Carpetbomb and PDF embedded executables). The integrity guarantee is that existing binary files which are b-valid cannot be modified by the attacker. It is also not possible to delete b-valid binaries. As d-mode is orthogonal from other privileges, i.e. system administrator privileges, these guarantees apply even for privileged processes in d-mode. An important consequence is that even if a software running in d-mode is successfully attacked, the attack cannot be made persistent through binaries as it cannot write b-valid binaries nor can it modify any binaries. Since the operations considered on binaries are execution, loading and file operations, this completes the analysis of d-mode.

Security of i-mode: Changing from d-mode to i-mode using modetrans requires authenticated privileges for the operation (R14), thus, no processes in d-mode can enter i-mode by themselves. So the threat model is that an attacker needs to get the user to enter i-mode, e.g. a social engineering attack. However if BInt+tr∨ is used, then modetrans can be a rare and unusual operation making is more difficult to social engineer unlike UAC in Windows where the user is "trained to click allow".

There are two cases to consider whether the user installs the malware in a new software domain or existing domain. Firstly, if it is a new domain, as the malware installer cannot modify existing b-valid binaries, their integrity is assured. However, the malware can install new binaries which might be loaded into existing software, e.g. the Safari Carpetbomb DLL attack, if there is an exploitable vulnerability. The BInt+tr∧ model (and BInt+tr∧W) can prevent this since the malware should not be in the whitelist. Our prototype additionally keeps a binary database of binaries and their software domains and also logs of binary usage and loading relationships, allowing attacks to be detected and be removed more easily. Secondly, if it is an existing domain, the malware can modify binaries of the above BInt models except in the BInt+tr∧W model which only allows modification with another trusted binary of the same domain. Thus, BInt+tr∧W being the most restrictive model prevents binary integrity attack in both cases.

The damage that can be caused by the malware in the other BInt models depends on the domain. For critical domains such as microsoft (for all the system binaries), the malware can affect all software as programs use Windows system DLLs in the microsoft domain. To reduce the impact of such attacks, one approach is to require extra privileges such as a separate password for critical domains. Furthermore, unlike the Windows UAC privilege escalation, the binary database in the prototype can be used to explain whether a binary is relevant to the software domain.

The extensions discussed in Sec. 5 also reduce the threats from i-mode.

Security of t-mode: Like i-mode, t-mode also requires authentication for the privilege escalation. However, t-mode behaves like d-mode in terms of binary integrity, a t-mode process cannot modify b-valid binaries (R6). Thus, a malicious t-mode process cannot introduce new binaries to d-mode processes. However, tmode processes can load b-invalid binaries (R9) which allows for binary attacks to these processes. T-mode is meant to be a special exception, it is like i-mode in that most software and processes do not run in this mode. Since in t-mode, any binary can be loaded, the threat model is whether the attacker can make the malware persist. However, in order to persist, it would need to be able to lure the user to authenticate and run it in t-mode every time, as it cannot execute/load in d-mode and t-mode does not affect binaries. We argue that unlike UAC, user authentication for i/t-mode is more controlled and without the problem that users tend to choose "always allow" [START_REF] Motiee | Do Windows Users Follow the Principle of Least Privilege? Investigating User Account Control Practices[END_REF]. The problem with UAC is that users do not know how to choose between allow or deny, they learn that deny just means the software fails, so they learn to click "allow".

A BInt Windows Prototype

We implemented a prototype in Windows XP of BInt models. We describe the implementation of basic BInt and mention differences for other models. We also discuss some implementation features for our models to deal with special features in Windows as BInt is generic and the model is not targeted for Windows. We use a kernel driver in Windows XP to intercept native calls (Windows system calls) for binary loading, file reading, file modification, process creation and some other operations.8 It also maintains the labels of processes and binaries. As our implementation works inside the Windows kernel, it allows us to apply all the rules of BInt to all processes and binaries in Windows.

Our prototype is meant to be a proof of concept to show that BInt can be implemented efficiently, provide security against binary attacks and be compatible with existing software. Nevertheless, the prototype shows the viability of BInt and that it would be relatively easy for Microsoft to implement. It should be clear also that building a version of BInt in another operating system, e.g. Unix, is relatively straightforward.

For R8-13 in Table 1, we intercept the NtCreateSection native call, which is necessary for binary loading. If the execution mode is d-mode and the binary is b-invalid, NtCreateSection fails resulting in the load/execute failing. For R1-7, we intercept the ZwCreateFile call, which opens or creates a file and returns a handle. For R11-13, we use the kernel API PsSetCreateProcessNotifyRoutine to inherit execution mode and software domain in the child process. For R14, we use IOCTL (I/O control) to implement the system call-like modetrans operation.

Most of the corresponding rules in BInt+tr are implemented in the same way as BInt. The T (f ) signature verification in BInt+tr is cached so that multiple loadings only need a single verification unless the binary is modified. This caching optimization is similar to that in [START_REF] Halim | A Lightweight Binary Authentication System for Windows[END_REF] which has been shown to be efficient with negligible overhead for real applications. File writing, renaming and deletion are monitored through the ZwCreateFile and ZwDeleteFile kernel APIs.

We assume all file modifications are under the control of the operating system kernel. This assumption can be invalid in some cases. When the system mounts a network shared file system, (e.g. through SMB) an attacker can change the binaries outside the system. Similarly, files can be changed when the system is offline. We call such files, unmonitorable files. To prevent these attacks, we use file signatures to detect modification. A binary database stores information about files, signatures, modification history and other metadata. We also generate logs of how binaries were used which is useful for explanations and creating special exceptions, e.g. execution mode policy. Log maintenance is done outside the kernel. For unmonitorable b-valid files, their signatures are updated immediately after the file is modified. For binaries that just come online, we verify the signatures once for each binary and cache the result [START_REF] Halim | A Lightweight Binary Authentication System for Windows[END_REF]. We optimize the signature verification with a lazy way of updating signatures to reduce the overhead of signature verification. We store normalized internal kernel paths to disambiguate Windows 8.3 filenames, long file names and symbolic links. For the NTFS filesystem, we use the object ID to disambiguate hard links.

In Windows, there is no distinguishing feature of a binary (the filetype is only a convention, i.e. an executable need not have file type .exe or .com), other than its format. We test whether or not the file is a binary by reading the file header. This makes i-mode more costly than other modes since only i-mode creates bvalid binaries. We modify the semantics of Windows slightly so that files opened for writing in i-mode are in exclusive mode to simplify signature creation. We do not expect this to be a major restriction as the installer is likely to be creating files sequentially. When p closes the file handle of f , the file contents is now complete and f 's signature can be re-computed (lazily). In principle, signatures only need to be maintained for non-monitorable files. However, to reduce the impact of offline attacks, we choose to maintain signatures of all b-valid binaries and critical files.

Since a software installer may launch several helper programs to accomplish the installation, we need to ensure all helper processes are labelled with the same execution mode and software domain. This is accomplished by mode and domain inheritance (R11-13). BInt assumes that all helper processes are the child (or descendant) processes of the first installer process. While the assumption holds for most installers, there is an important exception. MSI (Windows Installer) is a generic installation engine for installing and updating software on Windows. It is used for both Microsoft and non-Microsoft software. MSI makes use of a service (daemon) process to perform installation. The service process is always running and is not part of the process hierarchy of the original installer. Dealing with MSI requires some minor extensions to how i-mode works. We monitor the communication channel, a named pipe \Pipe\Net\NtControlPipeX, between the installation process and the MSI service. When an i-mode process triggers the service to start installation, the service is switched to i-mode with the same domain as the triggering process. When the installation terminates, the service is switched back to d-mode. As the MSI service is used atomically, there is no interference between concurrent requests.

We now illustrate how BInt is used in our Windows prototype. When the system is booted, the initial process(es) run in d-mode, thus all subsequent processes run in d-mode unless modetrans is used. We have implemented a command-line modetrans utility which authenticates the user using a password and executes a user-specified program in a user-specified mode and domain.

Since auto-update program should always run in i-mode, we introduce an execution mode policy which simplifies system usage by predefining special cases where the operation of modetrans can be performed automatically. For example, Windows auto-update (wuauclt.exe), is specified to run in i-mode and the microsoft domain. Finally, the mechanisms also protect the BInt policy files, modifications to the policies require user authentication.

The execution mode policy is to make usage of BInt more transparent so that users do not need to explicitly go into i-mode. This policy is small and mostly for well-known cases with a few exceptions. Thus, it is much easier to deal with and maintain than more complex policy-based models.

Evaluating BInt on Windows

We evaluated our prototype with the basic BInt model as the other models would need additional external trusted third party providers. In terms of performance, the main mode is d-mode as other modes should only be used more rarely. As we employ caching to monitor binaries, once a binary signature has been checked, there is little overhead (as the implementation of signed binaries in [START_REF] Halim | A Lightweight Binary Authentication System for Windows[END_REF]). Since many binaries are shared, we find that once the system has started and some binary has been loaded before, the overheads for real applications are negligible and we did not notice any significant difference between running our prototype and normal Windows.

We evaluated d-mode on the following common binary attack vectors: directly running a b-invalid executable from the GUI Windows Explorer shell (a social engineering attack) and the cmd shell; PDF attack on Acrobat Reader using a PDF embedded binary [5]; loading a b-invalid driver; starting a b-invalid service; loading b-invalid shell extensions and Browser Helper Objects (exploits a vulnerability where binaries could be loaded as a Windows help file [4]); and loading b-invalid DLLs by PATH manipulation (such as DLL planting attacks [7, 8]). While our security analysis already shows that d-mode prevents these attacks in the abstract model, the evaluation confirms this for the prototype.

We tested compatibility with the binary lifecycle of common Windows software by installing, running and uninstalling the following applications: Internet Explorer (IE, highly integrated into Windows), Winamp (music player with 88 binaries), Yahoo Messenger (instant messaging client with 55 binaries), Firefox (32 binaries), Google Chrome (137 binaries), Adobe Acrobat Reader (31 binaries) and Java Development Kit (229 binaries).

IE tests Microsoft software installation. The software domain is microsoft due to the highly integrated nature of Microsoft software in Windows. In fact, IE modifies several Windows system DLLs. No problems were observed during installing and running IE. Windows update handles the auto update of Windows related software including IE, this occurred transparently without problems.

The Winamp installer uses its own Nullsoft installer. No problem was observed during running and uninstalling Winamp. Yahoo Messenger uses a networkbased install, the installer is an initial installer which downloads a much larger installer. The installer tries to upgrade the Flash ActiveX plugin flash.ocx if it is out of date. This action is blocked as the software domains do not match. However, this is not a problem as the Flash plugin can be updated separately. We noticed that a YahooAUService.exe service is created for auto-update. In order for the auto-update to work transparently, we should add YahooAUService.exe to the execution mode policy to run in i-mode with the Yahoo domain.

No problem was found during Firefox installation. Auto-updates are handled by updater.exe in the Firefox software domain. For transparent update, it is added to the execution mode policy. No problem was observed for Chrome. Reader and Java Development Kit use the MSI engine which is handled transparently without any user interaction.

We tested typical software which cover a range of mechanisms for installation, uninstall, and update. We found that usage scenarios for the software lifecycle aspects are usable with little effort needed. In some cases, the security policy achieves complete transparently. For full transparency, the execution mode policy is used with a minimal specification. This can be done manually immediately after installation if the user knows which program does the update. It can also be done at the first time the updater performs the updates. In this case, the user will be notified about the attempt to modify binaries. Information from the binary database and logs can then be used to set the execution mode policy. Alternatively, auto-updaters can be run manually in i-mode as a more secure alternative which does not rely on any execution mode policy specification. Naturally that requires a bit more effort on the part of the user. If a more secure policy is needed we should expect that it needs some information but it should be sufficiently easy to specify and maintain without extensive analysis and expert knowledge, which is how we designed BInt.

The FInt Model

BInt only covers binaries but the integrity of non-binaries may also be important for the security of the system. For example, the attacker can modify the Java class files used by the Java compiler to insert malicious bytecode even though neither the Java virtual machine nor compiler is compromised [START_REF] Thompson | Reflections on Trusting Trust[END_REF]. An attack can modify a good script (.bat) into a malicious one. Without modifying the web server binaries, the attacker can change the web server's configuration file or PHP script to steal data or modify the web site. action L m (p) requires result rule We generalize BInt to protect integrity of any file. The use of files which are not binaries is quite different from binaries. Firstly, the operating system does not distinguish between an interpreter executing a script and reading a data file. Usually we only want to protect the integrity of the former. Secondly, while there are usually many more non-binaries than binaries, only a small fraction of the non-binaries is critical to security of the system. Thirdly, the semantics of non-binaries is program specific, unlike binaries which the operating system understands, e.g. a malicious Perl script is significant when opened by the Perl interpreter, but not when opened by a text editor.

p create f d-mode true L d (f ) := ⊥ 1 f t-mode true L d (f ) := ⊥ 2 f i-mode true L d (f ) := L d (p) 3 f p read f d-mode α (see caption) 4 f t-mode true 5 f i-mode true 6 f p write/delete f d-mode L d (f ) = ⊥ 7 f t-mode L d (f ) = ⊥ 8 f i-mode L d (f ) = ⊥ ∨ L d (f ) = L d (p) L d (f ) := L d (p) 9
Due to these differences, we adopt a different approach to protecting the integrity of non-binaries. Only files defined by a FInt policy are protected. Essentially the FInt policy specifies what pathnames are critical to certain software. This policy can be specified on a per-program or per-domain basis. We remark that other variants of FInt are possible, we present FInt as a conservative extension of BInt.

The FInt policy consists of a list of subjects. Each subject is associated with a list of objects (pathnames) and associated action. The subjects and objects correspond to processes and files in the operating system. The subject is defined by a pathname of a binary or a software domain; and the object is a rule for the subject defined by a regular expression for a pathname along with the following actions: allow, deny, or verify. Allow means the files are allowed to be read/loaded. Files matching the allow rule are considered to be not critical to the program. Deny means the files are denied from being read/loaded. Verify means that the reading/loading is allowed depending on the execution modes and software domains of the process and file. The FInt policy extends BInt (specifically, rules R4, R11-R13) by applying to all files including binaries.

More than one rule can be specified for a subject. The action specified by the first matching rule is taken. The default action (none of the regular expressions match the path) is verify for binary and allow for non-binary. This is to make FInt consistent with BInt when no FInt policy is specified.

In FInt, non-binaries are labeled with software domains similar to BInt. The default label is ⊥ for all files unless otherwise created with a different domain which extends the notion of b-invalid (L(f ) = ⊥) and b-valid (L(f ) = ⊥) to all files. We introduce file execution modes in FInt which add to those in BInt. New file execution mode of a process p are denoted by L m (p), namely: d-mode , t-mode , and i-mode . Table 2 formalizes FInt for non-binary files. We add a file execution mode policy which specifies which programs should be automatically executed in which file execution modes. For example, the Java compiler can run automatically in i-mode so that the compiled class file will be b-valid, and is unmodified by anything else when used by the Java VM.

In order to prevent a program from (accidentally) reading files created by other programs (e.g. malware), we introduce an optional flag owner for each policy rule -the flag means that the file read/loaded must not only be b-valid, but also have the same software domain as the process (see Ex3).

One motivation for FInt policies is they can be used to construct specialized behavior for FInt. It can also be used to create special security policies or restrictions. We give some examples of how to use FInt policies.

Ex1: The following simple policy protects all batch files for the CMD shell:

[c:\windows\system32\cmd.exe] verify .*\.bat

Ex2:

The following policy verifies Java bytecode coming from .class and .jar files except for a project directory. The purpose is to allow modification of the Java code under development by non-JDK program such as IDEs. This policy is shared by programs such as java.exe and javaw.exe (GUI version of java) in the JDK software domain. Ex3: The following policy prevents Firefox's built-in JavaScript modules and extensions from being hijacked by third party program. It uses the "owner" flag. Ex4: In order to prevent the web server from being exploited to launch a cmd shell, one may run the web server in a more restricted environment with cmd.exe blacklisted by the following policy. Even without this policy, the web server is already protected as binaries which are not b-valid cannot be executed. Thus, if an attacker breaks in, they cannot run their own binaries but are restricted to the existing b-valid binaries. This policy further reduces the allowed binaries by denying the cmd shell.

[apache] deny .*\\cmd.exe

We discuss further extensions and possibilities for BInt for which there is lack of space to go into the details. File Deletion: For simplicity, the uninstaller runs in the same execution mode, i-mode, as installer and updater. This allows the uninstaller to add new binaries. We can prevent this by introducing a u-mode, which is more powerful than dmode and less powerful then i-mode. In u-mode, the process can delete binaries with the same software domain or ⊥, so that it can delete its binaries. Binaries created by a u-mode process are ⊥, so that it cannot introduce new binaries. We remark that as an alternative to deletion, the label can simply be downgraded to ⊥ if the binaries are to be retained but not executable or loadable. Software Dependencies: In BInt, software domains are treated equally, i.e. a process running in one software domain can load a binary of another software domain. If a user accidentally installs a malicious binary, it can be loaded into all processes. To prevent this, we can incorporate software dependencies into BInt, so that a process can load a binary if the software group of the process depends on the group of the binary. This adds a partial order relation while BInt only needed equality. For example, the dependencies can specify a plugin of a web browser can only be loaded by the browser but not other software. The dependency information can either be specified during software installation or come from a trusted third party such as the software developers. Sandboxed Domains: BInt requires i-mode to first install software before use, which may be considered troublesome to some users, i.e. users expect to be able to run a software immediately after downloading. We can use the idea of a sandboxed domain to allow immediate execution while still prevent the new binary from being loaded by other software. Binaries created by d-mode or tmode process are assigned a new sandboxed software domain (instead of ⊥ in BInt) -the new domain is denoted by newsb. Any binary can be executed in d-mode but if the binary is from a sandboxed domain, the process label also becomes sandboxed (a modification of R11). Thus, a downloaded binary can be executed immediately. However, to prevent malware from automatically executing downloaded binaries, when a sandboxed domain is executed for the first time, a UI prompt (with the creator's software domain, creation time, binary path, etc.) will ask for permission.

In summary, we have proposed a flexible family of binary integrity models which are designed to handle dynamic creation, modification and deletion of binaries in their lifecycle. Our models combine integrity of the binaries together with trust to protect against typical attack vectors which exploit the use of binaries which is a major headache in Windows. Our models are suitable as a security enhancement for Windows since the large attack surface of Windows leads to many binary attacks which BInt models prevent. Our prototype demonstrates that these models are practical and easy to use. As binary attacks are commonplace in Windows, we believe what is needed are simple policy mechanisms which give a good tradeoff between usability and security. BInt does not deal with code injection attacks but it can be combined with other runtime security mechanisms which do that, e.g. ASLR, NX, etc.

While we have focused on Windows, the BInt models are general and can be applied to other operating systems. Although Windows is where BInt would have the biggest benefit, there are also documented attacks on Unix such as autorunstyle USB attacks in Linux [START_REF]USB Autorun Attacks in Linux[END_REF] and the Flashback and Mac Defender malware on Mac OSX. We also propose FInt as a conservative extension of BInt to protect the integrity of non-binary files. We believe that the recent ShellShock bug in bash (a script injection vulnerability regarded as critical in most Unix/Linux systems) can be mitigated with extensions to our models.

  f p modetrans authentication change L d (p) and L m (p) 10 f Table 2. Rules for FInt. Assumes the files are non-binary. α: Apply the FInt policy for pathnames. If the result is "verify", the condition is: (L d (f ) = ⊥ (when owner flag is not set)) ∨ (L d (f ) = L d (p) (when owner flag is set))

  \\projects\\foo\\.*\.class allow E:\\projects\\foo\\.*\.jar verify .*\.class verify .*\.jar

  [firefox] verify owner C:\\Program Files\\Firefox\\.*\.jar verify owner C:\\Program Files\\Firefox\\.*\.js verify owner C:\\Program Files\\Firefox\\.*\.xul

A short paper briefly describes a basic form of BInt[START_REF] Wu | Towards a Binary Integrity System for Windows[END_REF].

For simplicity, directories and threads are not modelled but are easy to add.

We assume the user is familiar with the usage and principles of BInt. The user should not launch Firefox from the installer since normal software execution should be in d-mode. However, similar to Windows UAC prompts, warnings can be issued when executing a new binary in i-mode.

This changes the semantics of file write so that changes behave like a shadow file until it can be verified when the file is closed. Self-signing[START_REF] Wurster | Self-Signed Executables: Restricting Replacement of Program Binaries by Malware[END_REF] also needs to work in a similar way.

E.g. a vulnerability in the network code in the operating system might allow an attacker to gain arbitrary code execution within the kernel with an external network request, however, this is not a binary vulnerability or exploit.

We use Windows XP, later versions require signed drivers.

This research is supported in part by the National Research Foundation, Prime Minister's Office, Singapore under its National Cybersecurity R&D Program (Award No. NRF2014NCR-NCR001-21) and administered by the National Cybersecurity R&D Directorate.


Andrew Wong

Vicky Liu
email: v.liu@qut.edu.au

William Caelli
email: w.caelli@qut.edu.au

Tony Sahama

An Architecture for Trustworthy Open Data Services

Keywords: Open Data, Integrity, REST, Security, Public File

scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

During the course of his doctoral study, Roy Fielding generalized the architectural principles that drove the Web conceived of by Tim Berners-Lee in the early 1990s and presented these principles as an architectural style which was underpinned by a framework of constraints. This framework was named Representational State Transfer (REST) [START_REF] Fielding | Architectural styles and the design of network-based software architectures[END_REF] and systems which adhere to this framework are called "RESTful" systems or services. Because of the REST framework's ease of use and deployment, it has since been used in a variety of other development methodologies, including web services and application programming interface (API) development, and has since become a serious rival to the use of the earlier Simple Object Access Protocol (SOAP) [START_REF] Box | SOAP: Simple Object Access Protocol[END_REF] which is a successor to the Remote Procedure Call (RPC) programming style. These SOAP and REST based APIs have been used to communicate data and information in many fields, most recently, Open Data.

Open Data is data that can be freely used, shared and built-on by anyone, anywhere for any purpose [START_REF]Open Knowledge Foundation Blog[END_REF]. The recent global trends towards Open Data have organizations and governments relying on these APIs to communicate Open Data in a greater extent than before.

One of the key advantages of Open Data is that it increases the availability of data for consumers in decision making as well as providing potential for massive cost reduction through implicit outsourcing of information system development. At regional governmental level, a combination of Open Data with appropriate interrogation programs could possibly replace physical publication of such documents as guidebooks, listings, etc. The active interest and support by various national and international non-governmental organization as well as state and federal government sponsored 'hackathons' such as GovHack [START_REF] Govhack | [END_REF] and HealthHack [START_REF] Healthhack | [END_REF] aiming to develop new applications that use Open Data also could lead to a strong upsurge in the use of Open Data in various fields.

As the capacity for acquiring and storing data increasing from year to year and with data analytics exerting greater influence on decision making than in years past, trust has to be placed in not just the processes and algorithms used to analyse data, but in the authenticity and integrity of data as well. There is now a fast developing trend for enterprises; both public and private, to incorporate Open Data with proprietary and private data collections in order to provide better decision making and other reports. However, how can users trust conclusions or decisions made on the basis of results obtained from largely, untrusted data?

An adversary, wishing to use any means necessary to cause disruption, may wish to misuse the Open Data movement to achieve this disruption within the society by: 1. Diverting Open Data requests to a fraudulent site containing fraudulent datasets 2. Insertion of a fraudulent dataset into a legitimate site 3. Deliberate modification of a legitimate dataset 4. Denial of Service should Open Data become an integral and essential part of a community service Therefore, it becomes of vital significance to ensure the authenticity and integrity of Open Data in order to placing trust in decision making based on that same Open Data, for users, businesses, industry and government alike.

Paper Scope

Because of the nature of Open Data, methods such as encryption which is aimed at the confidentiality aspect of data may not be completely relevant in the broad philosophy of Open Data, but may be briefly discussed. This paper addresses development of trust in the usage or adaptation of Open Data through the incorporation of appropriate authentication and integrity parameters for data included in end-user Open Data applications by developers. The principle here is that the average person would not normally access raw Open Data collections but would view them through the lens of an appropriate application. The user would therefore need to be able to trust both the authenticity and integrity of data supplied by the application.

The proposed architecture makes use of the Domain Name System Security Extensions (DNSSEC) for host/server verification. However, the full description of DNSSEC functionality lies outside the scope of this paper, and will only be briefly discussed in relation to how it fits into the proposed architecture as a whole. It should be noted that DNSSEC does not use digital certificates but rather a public key hierarchical registry.

The paper will also discuss the proposed architecture's use of a public key hierarchical registry and digital signatures instead of the traditional certificate authority for the authentication of data publishers and integrity of datasets.

3

Related Work

Trustworthy Open Data

Open Data, which at its core, is the idea that certain types of data should be freely accessible to the public has its roots in the concept of open access to scientific data in the 1950s [6]. In more recent years, researchers have indicated the potential benefits of using Open Data analytics for positive effect in various fields [START_REF] Arzberger | Promoting Access to Public Research Data for Scientific, Economic, and Social Development[END_REF][START_REF] Davies | Open data, democracy and public sector reform. A look at open government data use from data[END_REF][START_REF] Molloy | The open knowledge foundation: open data means better science[END_REF][START_REF] Samwald | Linked open drug data for pharmaceutical research and development[END_REF][START_REF] Zuiderwijk | The potential of metadata for linked open data and its value for users and publishers[END_REF] and coupled with the rise of Open Government [START_REF] Janssen | Benefits, adoption barriers and myths of open data and open government[END_REF][START_REF] Kassen | A promising phenomenon of open data: A case study of the Chicago open data project[END_REF][START_REF] Zuiderwijk | Open data policies, their implementation and impact: A framework for comparison[END_REF], the Open Data movement stands to make even greater impact in the near future. However there are certain challenges that Open Data faces, not the least of which is ensuring data quality and fostering trust in Open Data [START_REF] Jaakkola | Open data: opportunities and challenges[END_REF]. Strong [START_REF] Mazon | Open business intelligence: on the importance of data quality awareness in user-friendly data mining[END_REF] and later Mazon [START_REF] Telikicherla | Enabling the development of safer mashups for open data[END_REF] recognize "fitness for use" as being the definition of data quality and an important criterion for data analytics and business intelligence, and security plays an important role in ensuring both data quality and trust. A database search returned few works relating to on methods for Open Data security. Telikicherla and Chopella [START_REF] Eckert | RESTful open workflows for data provenance and reuse[END_REF] propose a library for secure web application development as a means of preventing "frame busting" and other attacks in HTML5 based Open Data mashups. Eckert et al. [START_REF]CKAN instances around the world[END_REF] present a workflow model which preserves provenance for Linked Data and can be applied to Open Data. These approaches have their merits in the area of browser security and preserving provenance for data, however, as Open Data depends on the ability to transmit data that can be verified as both coming from an authenticated source while retaining integrity through the transmission process and therefore is trustworthy to the user, this issue still needs to be addressed.

Security for REST

The United States, United Kingdom, Japan, and Australia among others, use a software called the Comprehensive Knowledge Archive Network (CKAN), an open source data management platform to manage and publish their Open Data [START_REF]Socrata Open Data Portal[END_REF]. CKAN's Action API is based on the RPC programming style. Another well-known Open Data Management Suite is Socrata. The Socrata Open Data API (SODA) provides an open, standards-based REST API [START_REF]CKAN Multisite Draft Proposal[END_REF]. In the case of the United States, the wide variety of government services and organizations has led to the use of both CKAN [START_REF]Socrata Open Data API[END_REF] and SODA [START_REF] Comerford | Why REST security doesn't exist?[END_REF] at the state and federal government levels.

As APIs for Open Data is mostly disseminated through the platform of the World Wide Web (WWW), and the WWW is based on REST principles as coded by Fielding [START_REF] Fielding | Architectural styles and the design of network-based software architectures[END_REF], in order for Open Data to be secure, REST also needs to be secure. In Fielding's thesis, REST was designed to provide simplicity of implementation and scalability but has no pre-defined security protection mechanisms [START_REF]Web Services Security: SOAP Message Security 1.1[END_REF] when compared to SOAP, which uses the WS-Security [START_REF] Forsberg | RESTful Security[END_REF] standard. In response to this, several authors have recently suggested mechanisms by which to provide security for REST:

Forsberg [START_REF] Peng | An extended UsernameToken-based approach for REST-style Web Service Security Authentication[END_REF] proposed an approach where content protection was based on keys being delivered to clients via secure session. Forsberg's approach eliminates the need for repeated SSL/TLS encryption of cached content. Forsberg further notes that their solution is adjusted to match better with caching for data that requires confidentiality protection. An approach which used extended HTTP headers to effect extended username tokens was proposed by Dunlu et al. [START_REF] Serme | Enabling Message Security for RESTful Services[END_REF] for user authentication. A secondary password for the username token was required in order to avoid leakage of user password. The approach proposed by Serme et al. [START_REF] Lee | Defense against REST-based web service attacks for enterprise systems[END_REF] had some similarities to Dunlu et al. where they used extended HTTP headers, except that Serme's approach uses the HTTP headers to convey digital certificate and encryption information.

Lee and Mehta [START_REF] De Backere | Design of a security mechanism for RESTful Web Service communication through mobile clients[END_REF], investigating some of the security threats to REST-based Web Services concluded that although message encryption by HTTPS was a costly protection method, HTTPS-based data transfer was the best method to ensure data confidentiality. Backere et al. [START_REF] Diffie | New Directions in Cryptography[END_REF] states that the best solution to the RESTful security problem, or the one most conforming to RESTful principles, is to differentiate between messages that need to be encrypted and those that do not, that a message is notmodifiable, and that replayed messages be avoided. They propose a login and REST resource access mechanism that leveraged these concepts.

There is a common consensus that it is necessary for appropriate security mechanisms to be employed in REST Web Services, however the means of accomplishing this as well as the security properties to be protected vary from approach to approach. Most of the solutions presented by these authors however, focus on authenticating the user or protecting the confidentiality of information held in RESTful systems while using certificate-based Secure Sockets Layer/Transport Layer Security (SSL/TLS). This however, begs the question: Is it necessary to protect the confidentiality of publicly available Open Data, or even to authenticate users of Open Data?

The answer to this question is: Open Data by its very nature is public data, therefore it should be viewable by the public and not restricted by confidentiality mechanisms. With this, authentication of the end user for read-only access to Open Data is not strictly necessary. Having said this, restricting access to the methods that can be used to alter Open Data resources to authenticated entities, such as the original publisher of the data, or other authorized parties is still required. An important quality that was brought up by Backere et al. [START_REF] Diffie | New Directions in Cryptography[END_REF] which relates to Open Data is that messages and content should be unmodifiable, which basically refers to the integrity of Open Data resources and collections even as they are transferred and cached over the Web.

Public Key Infrastructures

There are two aspects to Open Data; 1) the management of Open Data collections, one of which involves actions by an authoritative source like adding, modifying or deleting datasets, and, 2) the usage or modification of datasets post-addition. Both of these aspects require authentication that: 1) The host of the data is genuine, and, 2) the data has been published by an authentic source, and, 3) the data being transmitted itself is genuine and remains unchanged through the communication process. This authentication can be accomplished through the use of message digests and digital signatures. Binding Diffie and Hellman [START_REF] Kohnfelder | Towards a practical public-key cryptosystem[END_REF] proposed a "public file" which could be used as a central authority for the binding of a specific identity to a particular public key for authentication purposes, thereby establishing a hierarchy of trust. Because of the technological limitations of the time, this approach has proven unfeasible when compared with the public key certificate concept proposed by Kohnfelder [START_REF] Clarke | Conventional public key infrastructure: An artefact ill-fitted to the needs of the information society[END_REF]. The public key certificate authentication scheme based on Kohnfelder's thesis is now ubiquitous, however, despite the technological barrier for the use of the" public file" no longer being applicable and issues with public key certificate management that have been highlighted by Clarke [START_REF] Rivest | Can we eliminate certificate revocation lists?[END_REF], most notably complexity and the problems with certificate revocation mechanisms.

Rivest attempts to address the issue of certificate revocation by proposing that proper certificate infrastructure organization can allow a signer to present a collection of certificates as evidence of authenticity [START_REF] Mcdaniel | A response to "Can we eliminate certificate revocation lists?[END_REF]. Another paper authored a few years later by McDaniels and Rubin [START_REF] Wendlandt | Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing[END_REF] state that addressing PKI requirements in large, loosely coupled environments using certificate revocation lists is difficult and a web environment based on REST, as envisioned by Fielding, is designed to be a large, loosely coupled environment.

There have been recent attempts to address the problems with public key certificate based authentication and trust through initiatives that leverage the abilities of multiple certificate notaries, such as the Perspectives Project, [START_REF] Marlinspike | SSL and the Future of Authenticity[END_REF] and Convergence [37]. The Perspectives Project and Convergence provide trust agility in which the user is given the ability to decide which party they wish to trust for authentication of certificates. In general, these initiatives provide trust that the certificate is genuine by leveraging multiple certificate notaries to provide additional trust perspectives on the Certificate in question.

However, in this emerging landscape of Open Data, a distributed trust model may not be the answer as usage of Open Data depends on whether or not a user trusts the owner or original creator of the Open Data. If that owner or creator is not a reputable source, or if the identity of said owner cannot be verified, then any data coming from that source is untrustworthy. In other words, an instance of a public key must be verified as belonging to a genuine entity, taking into account the threat of the addition of false identities and/or public keys, in order for data gleaned from that source to be considered trustworthy and/or having authenticity and integrity.

Proposed Solution

This paper proposes a Trustworthy Architecture for Open Data Systems (Fig. 1.) which would serve as a precaution against tampering, enabling users to know when a particular resource is genuine or has been tampered with, thus augmenting the REST framework. As mentioned in a previous section, the SSL/TLS level encryption of request-response messages represents an expenditure of processing resource which is not critical for communicating Open Data. However, measures to protect message integrity and authenticity to ensure trustworthiness are still required.

Key Components

The architecture proposed hinges on several key components, a Key Generation component, a Public Key File, DNSSEC and a Verifier Module which interfaces with regular REST framework activity as needed.

Certification Authority vs Public Key Registry.

Effective key management is essential for the smooth operation of cryptographic systems. In regular circumstances, a trusted Certification Authority is responsible for issuing digital certificates and maintaining certificate revocation lists, and is also responsible for the generation of cryptographic key pairs and digital signatures. Public Key Record API Renderer would be the normal procedure, however, given that Open Data is of its own essence, "open", proposing a complex certificate architecture including certificate revocation should be unnecessary. Moreover, access to confidentiality/privacy services and mechanisms is not required. It would seem reasonable, then, that each Open Data publishing entity could maintain its own public key, relevant to verification of data integrity alone, in an appropriately managed and controlled public key registry (PKR) file similar to the Diffie-Hellman concept of the "public file", in line with the design philosophy of DNSSEC.

Public Key File. The Public Key File is a central location where public keys associated with recognized identities may be retrieved. It is proposed that any entity wishing to publish Open Data generates a cryptographic key pair and submit the public key to the Open Data Public Key File maintained by this Registry (using the Key Generation and Signing Module). Users of Open Data will then be able to retrieve the appropriate public key to verify a signature from this central location.

Key Generation and Signing Module (KENNEL).

For ease of explanation the Key Generation and Signing module will be referred to as KENNEL. To become an Open Data Publisher, owners of Open Data first need to use KENNEL to generate a cryptographic key pair. This local generation of the key pair eliminates the need to securely transmit the private key over network channels and just exposes the public key, which is what the public key is designed for. The module then submits the generated Public Key to the Registry along with sufficient proof of identity over a secure channel (Fig. 2.). This information will be the basis of a record in the Public Key File. (Fig. 3 The Open Data Publisher is responsible for maintaining the secrecy of its Private Key, and uses this key in conjunction with a cryptographic one-way hashing function to generate a Digital Signature.

Verifier Module (HOUND).

For ease of reference, the Verifier will be referred to as HOUND. After address resolution with DNSSEC implemented is accomplished, a request for resources reaches the server and the server responds with the appropriate resource which is digitally signed. At the client-side, HOUND reads the server response, extracting signer's identity, retrieves the matching public key from its Public Key Record and verifies the digital signature.

A message digest is recovered by decrypting the digital signature with a valid public key and is compared to a message digest computed at the recipient end of the communication. If both digests are identical, then the response is considered to be authentic and retains its integrity. The operation of the verifier terminates and the content is then passed to the Renderer and is displayed in whichever format is applicable. If the digests are not identical, then the recipient is alerted to the fact that the resource may be fraudulent or has been altered in transit.

Open Data Public File

Public Key File Public Key Record

Open Data Publisher

Generates Key Pair Submitted Public Verification Key DNSSEC. The Internet Engineering Task Force has developed RFC3833 [38] the Domain Name System Security Extension specification to resolve various threats to the DNS using public-key cryptography to establish a chain of trust, which in practice each zone has a public key which is deposited in the parent domain for authentication purposes. Therefore, DNSSEC does not make use of digital certificates but rather a public key hierarchical registry.

In order for DNSSEC to be incorporated, the domain host first needs to have DNSSEC enabled on the server-side and the client needs to install a DNSSEC validator which can read verification information from the server.

Use Case Scenario

Communication without the proposed architecture. A request for data to a server follows a standard request-response paradigm. This is an example of a standard HTTP request for a resource without the use of the proposed architecture: Address Resolution is performed after the initial request is made by the Domain Name System. DNS uses Root or Authoritative Name Servers which are heavily supplemented by DNS caches as a workaround to reduce DNS traffic and increase efficiency. Caching DNS request-response records reduces load on individual servers but is vulnerable to DNS cache poisoning and other interception attacks.

After the 200 OK response, there is no further communication from hosting server and there is no provision for integrity verification. Content is then displayed. It is difficult to place confidence in the data because, as mentioned previously, without any security or integrity-checking mechanism in place, the file is still vulnerable to accidental corruption and interception attacks.

Communication using the proposed architecture. The following example illustrates use of the proposed architecture from the perspective of the end user:

Domain Name Server

Open Data Publisher In communication with the end-user, the proposed architecture does not change the request-response format of HTTP communication, but rather augments it with the previously mentioned security components. At this stage, as before, address resolution is performed, incorporating DNSSEC to authenticate the DNS Server and provide defence against cache poisoning or man-inthe-middle attacks. As mentioned in a previous section, a DNSSEC validator is installed on the client-side and validates the incoming content. After the address resolution is performed successfully, communications proceed as per normal and a response from the hosting server is received. As per RFC2616 [39], a successful request should contain a 2xx or a 3xx status code depending on the HTTP method used. If an error on the client-side is perceived, the server should return a 4xx status code but if an error occurs on the server-side a 5xx status code should be returned to the client.

In this case, the response contains a status code and the actual message which is digitally signed and accompanied by a digital certificate. The verifier module is then called to verify the integrity and authenticity of the received message. At the end of verifier module process, the message or content should be displayed if both the certificate and signature pass verification. The following is pseudocode describing the functioning of the verifier module: This procedure assumes DNSSEC is enabled. However, should DNSSEC not be available, HOUND should use HTTPS as a minimum for integrity to retrieve the appropriate public key from the Public Key File at the Registry for signature verification.

REST URI Interface with proposed architecture. Each dataset may contain one or more resource files, which is linked to a particular digital signature file and is associated with the identity and public key of the dataset owner/creator at the Registry.

Table 3. URI interface

When a GET request is called for a dataset, e.g. GET /datasets/sampledataset, the server returns a listing of resource files and their URIs. From the information in that list, a GET request may then be sent for an individual resource, e.g. GET /datasets/sampledataset/resource1, which should retrieve both the resource file and the associated digital signature. All the information is then used in the signature value with the algorithm described in Section 3.2. See Appendix 1 for a previously existing implementation sample of a signature verifier in concrete code.

Conclusion and Future Work

This paper proposes an architecture that uses digital signatures in conjunction with an associated public key file with the main goal to protect the integrity of Open Data communicated over the Web. This is a simplification of current public key certificate structures which use large revocation lists for certificate currency and have demonstrated problems in scalability and "certificate authority" trust.

The key element of this architecture is that it is based on DNSSEC, which is more appropriate to the new world of IPv6. The advantages of this architecture scheme is that it is far more scalable, not another certificate authority hierarchy with massive dispersion of key certificates which has of late become too widespread and unmanageable. With the use of a Public Key File, if the key is compromised; it is a simple matter of the single responsible entity replacing the key pair with a new one and reperforming the data file signing process.

Responsibility for authenticating Open Data is separated from any other certificate authority that might be used by the publishing entity. Under this proposed architecture, the Open Data environment does not interfere with the internal security schemes that might be employed by the entity. However, this architecture incorporates, when needed, parameters from the entity, e.g. person who authorized publishing as Open Data, at the time that datasets are created/added.

Fig. 1 .

 1 Fig. 1. Trustworthy Architecture for Open Data Systems

  If a certificate model is to be used then this Trustworthy Architecture for Open Data

Fig. 2 .

 2 Fig. 2. Open Data User Case Illustration

  Sample Dataset (URI: …/datasets/sampledataset)

Table 1 .

 1 Process of Fig.2. Open Data Publisher Process using KENNEL

	.)

Fig. 3. Role of the Open Data Certificate Authority in relation to the Open Data Publisher

Table 2 .

 2 Process of Fig. 4. Open Data User Case

	Steps Description	Process
	1 2 3	DNS Resolution Request DNS Resolver Response Verified using zone public key	DNSSEC enabled Address Resolution
	4 5 6	Open Data request Digitally signed Open Data response Signature Verifier begins operations	Open Data Resource Lookup
	7	Request for Public Key
	8 9	Public file responds with signer's public key Verifier extracts message digest from signature using signer's public key and verifies integrity of	HOUND Integrity Verification Process
		Open Data file

Future work will include the building of a proof-of-concept system using the architecture in this paper and performing benchmarking against regular systems in conjunction with penetration testing. An interesting philosophical question which may be studied in further papers is: what responsibility does an entity, whether private or public, take on when it makes Open Data available? Further study on the issue of Open Data and governance requirements must be done.


Alexandru Butoi
email: alex.butoi@econ.ubbcluj.ro

Mircea Moca
email: mircea.moca@econ.ubbcluj.ro

Nicolae Tomai
email: nicolae.tomai@econ.ubbcluj.ro

Data Confidentiality in Cloud Storage Protocol Based on Secret Sharing Scheme: A Brute Force Attack Evaluation

Keywords: cloud data, security, confidentiality, secret sharing scheme, brute force evaluation

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Certain studies like [START_REF] Subashini | A survey on security issues in service delivery models of cloud computing[END_REF] show that data security still remains the main barrier for cloud service adoption in business. While it is true that nowadays public clouds represent affordable data storage alternatives, outsourcing a company's storage increases data security risk and emphasizes the problem of unauthorized data disclosures performed by malicious insiders. This indirectly leads to mistrust among possible adopters, as complex or unclear SLAs fail to reduce the risks of information disclosure after moving it into the cloud. The need of built-in interaction mechanisms for achieving security by design is mandatory while it can build trust between the two involved parties [START_REF] Abbadi | A framework for establishing trust in the cloud[END_REF]. The challenge is to build mechanisms for public cloud infrastructures such that the confidentiality attribute is guaranteed through their own definition.

This paper is a continuation of the work conducted on Data Confidentiality in Cloud Storage Protocol (DCCSP) [START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF]. In this paper we evaluate the security strength of DCCSP using a brute force attack setup as a proxy. The implementation of DCCSP in a real system would help cloud adopters to assure a protection against unauthorized disclosure of sensitive data by malicious insiders or other attackers.

The remainder of this paper is structured as follows: Section 2 describes the addressed problem, section 3 overviews the DCCSP protocol, section 4 presents the conducted experiments and findings, while section 5 gives an overview of related or similar approaches. Section 6 concludes our work.

Background

In this section we give a short description of the main concepts used in our discussion. We consider two interacting parties: the cloud consumer and the cloud provider. The cloud consumer can be any user which contracts and use cloud storage resources to store her data. The cloud provider is an organization that owns, fully administers and rents cloud resources to the cloud consumer. Resources delivery to the cloud consumer is made according to a previously agreed SLA (cost, availability, security policies, usage etc.).

In our context the cloud consumer is willing to move data to a public storage cloud service. Due to cloud-specific resource elasticity achievable mainly through virtualization, the storage resources are managed and delivered in form of storage volumes. These may also be virtualized or not. We assume that the cloud consumer has access to multiple storage volumes from the cloud provider in order to save her data, according to the agreed SLA. The public cloud provider is a storage service provider which grants access for a cloud consumer to n distinct storage volumes(V 1 , V 2 , ..., V n ). Each such volume has a certain amount of storage space that the cloud consumer uses for storing data.

In our setup the cloud consumer holds and fully controls a private cloud infrastructure (like own managed servers and storage). On the other side, the cloud consumer has only limited control over the public cloud resources regarding data administration. This aspect may be considered a source of security risk and mistrust [START_REF] Rocha | The final frontier: Confidentiality and privacy in the cloud[END_REF].

DCCSP definition overview

In this section we give a brief description of the algorithms underlying the DCCSP protocol, detailed in [START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF]. This protocol insures that prior to the data storing into the public cloud, it will be secured by computing the secret sharing scheme on the user's private cloud. The secret is the file that holds sensitive information and the sharers are public cloud storage volumes. By this, only the cloud consumer knows the distribution pattern of the data into the public cloud. The protocol is transparent to any cloud infrastructure that fulfills the above assumption of instantiating multiple storage volumes, being implemented on the private cloud side as an interaction layer with the public cloud storage services. The file send phase of the protocol takes place when the user wants to store or update a sensitive file in the public cloud storage. Before the upload of the file, the protocol splits the file into several smaller data chunks, denoted by C 1 , C 2 , ..., C m . These chunks are stored into available storage volumes in public cloud in a way that the probability of reconstructing the initial file by a malicious insider or by an attacker is minimized. The protocol uses two algorithms to fulfill its purpose: I.A secret splitting algorithm [3, p. 993] that implements the strategy of computing each chunk with the optimum size from the information security point of view. It uses the Shanon entropy and Kullbach-Leibler information for discrete distributions as metrics for minimizing the useful information content carried by each chunk relative to the whole information in the original file. The total amount of information in the file is quantified by the Shanon entropy which computes the average information contained in a sequence of data [5, p. 367-368], while the Kullbach-Leibler measures "the distance" between informational content of a new chunk (I(c i )) and the entire file informational content(I(f )) [START_REF] Hsu | Probability, random variables, and random processes[END_REF][START_REF] Burnham | Model selection and multimodel inference: a practical information-theoretic approach[END_REF]:

I(f ) = - s i=1 P (x i )lnP (x i ); I(f, c i ) = s i=1 P (x i )ln( P (x i ) Q(x i ) ); (1)
P (xi) = probability of byte xi occurrence in file f , P (xi) = kx i
s where kx i equals with the number of xi occurrences in file f , and s is the file size in number of bytes; ln is the natural logarithm function; Q(xi) = probability of byte xi occurrence in chunk ci when xi is selected from the original file;

Q(xi) = kcx i s , kcx i = number of occurrences for byte xi in chunk ci;
As plot (a) in figure 2 shows, each chunk size is selected with regards of having it's calculated K-L metric as higher as possible compared with the original file entropy I(f ): I(f, c i ) >> I(f ) [START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF] II.A chunk distribution algorithm[3, p. 995] which implements the distribution of computed file chunks in the public cloud storage. These are distributed among available storage in a way that the probability of unauthorized reconstruction of the file is constantly minimized (eq. 2):

p(1) = t! (t -1)! P (1 -P ) t-1 = t • P (1 -P ) t-1 (2)
p( 1) is the probability of 1 successful reverse engineering modeled as Bernoulli trials; t is the number of trials; P is the event probability of choosing the right chunk in a trial calculated as a product of the two event probabilities: the probability of reconstructing the volume set used to store the file and the probability of reconstructing the right sequence of chunks in the original file, P = 1

C kv nv • 1 A kc nc [3, p.994-995].
The above strategy stores the file chunks in a manner that probability p(1) of obtaining 1 success of file reconstruction to be as small as possible regardless the number of trials t. The plot (b) in figure 2 depicts the evolution of calculated p(1) in the process as more chunks are being stored among 10 storage volumes. The p(1) values have an exponential decrease and are represented on a log10 scale chart for easier reading purposes.

A Chunk Distribution Dictionary (CDD) is used for each data chunk upload operation to be recorded into it. Each record in this dictionary has three key fields: [START_REF] Subashini | A survey on security issues in service delivery models of cloud computing[END_REF] The index of the chunk in the original file. This provides the exact position of the chunk within its belonging file; [START_REF] Abbadi | A framework for establishing trust in the cloud[END_REF] The virtual volume(s) where the chunk is stored. [START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF] The hash sum of the chunk for integrity check purposes. The file splitting process takes place on the private cloud side, the resulting chunks being sent to the public cloud in a random order and associated CDD is stored on the private cloud infrastructure too. By this, only the cloud consumer which is the owner of data is aware of the distribution scheme.

The file retrieve phase takes place when a file is accessed or downloaded from the public cloud infrastructure. The operation can be triggered only through the private cloud which stores the corresponding dictionary. The CDD is used here to identify every data chunk of the file together with its associated storage volume. Similar to the send strategy, the chunks are randomly selected for retrieval. Finally, based on the chunk index, the original file is reconstructed.

Experiments and results

In this section we present a set of experiments performed to evaluate the effectiveness of our DCCSP protocol. We used the CloudSim [START_REF] Calheiros | Cloudsim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms[END_REF] environment running the experiments. As experimental data we used files exported from an e-learning platform, containing records with sensitive user account details.

Experimental setup

The strategy of storing chunks into the public cloud storage is based on constantly minimizing the probability of successful reconstruction of the original file, mainly by a malicious insider. In order to evaluate the security strength of our protocol we have implemented a brute force attack simulation model which tries to reverse engineer the process of reconstructing the original file without prior knowledge of the chunk distribution dictionary. The simulation is based on a brute force search strategy which searches the storage volumes for data chunks files while trying to reconstruct the original file. As an output for bench-marking, it counts the number of trials needed for a complete retrieval of the original file.

The main issue in mistrusting the data protection in public cloud system is mainly related to the problem of malicious insiders, super-users or administrators which can easily gain unauthorized access to already stored data.

Assumptions:

a the attacker is a malicious insider which knows the exact total set of volumes used in storing the target file; b the attacker does not have knowledge about how chunks are distributed; c the attacker does not have knowledge of the right chunk order in the file; d the storage volumes are storing only the chunks of the targeted file.

The approach is an optimistic one which can be differentiated from a real world scenario by certain aspects like: the attacker does not have knowledge of the distribution records for chunk trial validation purpose after each chunk selection, the volumes may contain other data than targeted chunk files or it is likely for the attacker to not be able to know the exact volume set used in storing the targeted file. All the above are hardening the process of reverse engineering in a real world scenario.

Every file can be considered as a data chunk arrangement. The brute force strategy searches for a valid arrangement of data chunks. When the candidate arrangement is identical with the chunk arrangement of the original file, the search stops:

1. while unconsidered storage volumes exists, randomly select one; 2. on selected volume, search for the next valid chunk: a selected chunk is considered valid if it's position in the candidate arrangement built so far, is the same as in the original file arrangement;

We used two setups for a 1MB target file: (I) we varied the number of used volumes, keeping the number of file chunks constant at 4361;

(II) we varied the number of chunks from 100 to 100000 keeping the used volumes number constant at 50.

The output of these simulations were the number of Volume trials and number of Chunk trials. The number of Volume trials represents the total number of volume selections made in the brute force reverse engineering strategy. The number of Chunk trials is the total number of chunk selections made in the brute force search process.

Brute force trials

I. For the first setup, results are depicted in figure 3. We can see that volume trials have a linear evolution rapidly ascending from 44000 trials to 650000 trials as used volumes increase from 10 to 150. As for the chunk trials we can see that the figures are maintained at a high level, even when 10 volumes are used. Both charts indicate a low probability of unauthorized reconstruction of the file while the number of unsuccessful trials increase. II. In the second simulation setup, when the number of chunks is increased, figure 4 shows that both output indicators follow the same pattern of an exponential growth. Furthermore, we observe that when the number of chunks is above 10000, the number of trials rapidly increases towards infinity and rapidly lowering the probability of reverse engineering of the original file. Splitting a file in a higher number of chunks seems to be a better strategy because if we increase the chunks number, we can exponentially decrease the chances of breaking the protocol, while increasing the used volumes number, we decrease the chances of a security breach only linearly.

Related work

The existing data protection oriented cloud systems like Depsky [START_REF] Bessani | Depsky: dependable and secure storage in a cloud-of-clouds[END_REF] and Belisarius [START_REF] Padilha | Belisarius: Bft storage with confidentiality[END_REF] may be vulnerable to malicious insiders. These approaches use classic security concepts to protect data, like encryption which can be efficient but when comes to data processing, the access to data can be difficult. In contrast, DCCSP aims to minimize the issue of malicious insiders and protect data from unauthorized disclosure even against cloud administrators, without using a mandatory encryption step.

Other secret shared scheme approaches to data protection in cloud [START_REF] Fahl | Confidentiality as a service-usable security for the cloud[END_REF][START_REF] Kajiura | A file-distribution approach to achieve high availability and confidentiality for data storage on multi-cloud[END_REF]] make use of multiple cloud providers, while DCCSP uses multiple virtual storage from one single provider.

Similar to our brute force attack evaluation strategy, Galbally et al. [START_REF] Galbally | Evaluation of bruteforce attack to dynamic signature verification using synthetic samples[END_REF] employ brute force attack schemes to evaluate the strength of a HMM-based dynamic signature verification system. Also, in [START_REF] Mandal | Designing and performance analysis of a proposed symmetric cryptography algorithm[END_REF] the authors propose a hybrid RSA+Difie-Hellman symmetric encryption strategy which is mathematically evaluated against brute force attacks. [START_REF] Ahmed | Encryption efficiency analysis and security evaluation of rc6 block cipher for digital images[END_REF] evaluates the encryption efficiency to digital images against brute force attacks, statistical and differential attacks while [START_REF] Nalini | Attacks of simple block ciphers via efficient heuristics[END_REF] evaluates simple block ciphers using different strategies for brute force search like genetic algorithms or particle swarm optimisation.

Conclusions

This paper presents a continuation of work presented in [START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF] introducing DCCSP protocol for assuring a lower as possible probability of unauthorized data disclosure in public cloud storage services. The current work addressed the problem of evaluating the strength of DCCSP using a brute force search strategy. We found that the probability of unauthorized data reconstruction can be exponentially decreased by using a sufficiently large number of chunks. Also, we observed that increasing the number of used storage volumes leads to a linear decrease of unauthorized data reconstruction. This leads to the idea that DCCSP can be cost efficient by using a constant number of storage volumes (fixed cost) and leveraging the number of chunks for obtaining high security levels. As future work we aim to development of a new flavor of the splitting algorithm operating at the word level for text files. Also, we plan to experiment with this protocol into a real cloud infrastructure.

Figure 1

 1 Figure 1 depicts an overview of the protocol, which defines two main phases: the file send and file retrieve.

Fig. 1 .

 1 Fig. 1. Protocol overview.

Fig. 2 .

 2 Fig.2. Chunk optimal size computation[START_REF] Butoi | Secret sharing scheme for data confidentiality preserving in a public-private hybrid cloud storage approach[END_REF]

Fig. 3 .

 3 Fig. 3. Volume and chunk trials for 1 MB[4361 chunks] file when varying the number of used storage volumes.

Fig. 4 .

 4 Fig. 4. Volume trials when varying the number of chunks.

This work was cofinanced from the European Social Fund through Sectoral Operational Programme Human Resources Development 2007-2013, project number POS-DRU/159/1.5/S/134197 "Performance and excellence in doctoral and postdoctoral research in Romanian economics science domain".