Loading repository data…
Loading repository data…
zeutro / repository
The OpenABE library - open source cryptographic library with attribute-based encryption implementations in C/C++
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
OpenABE is a cryptographic library that incorporates a variety of attribute-based encryption (ABE) algorithms, industry standard cryptographic functions and tools, and an intuitive application programming interface (API). OpenABE is intended to allow developers to seamlessly incorporate ABE technology into applications that would benefit from ABE to protect and control access to sensitive data. OpenABE is designed to be easy to use and does not require developers to be encryption experts.
This bundle includes full source code, examples and three main sources of documentation:
The software is available for use under the AGPL 3.0 license.
Encryption is a method of encoding data that protects the confidentiality of its contents from unauthorized attackers. Traditionally, encryption was viewed as a tool to enable secure communication between a sender and a targeted recipient of information. For example, one might wish to store a message such that it can only be decrypted by the user bob@xyz.org.
Attribute-Based Encryption is a more expansive type of public key encryption that allows for flexible policy-based access controls that are cryptographically (that is, mathematically) enforced. Instead of encrypting data to a single user, it is now possible to encrypt it so that the data can be decrypted by anyone with credentials satisfying an arbitrary attribute-based access control policy.
In OpenABE, any string can potentially serve as an attribute. In addition, attributes can be numeric values and policies can contain ranges over these values. The set of attributes used will depend on the designated application.
In order to understand the capabilities of ABE, it helps to organize them logically into three variants.
Content-Based Access Control - for granting selective access later (e.g., cloud, email, big data, subpoenas).
In an ABE system for content-based access control, attributes are associated with a ciphertext and the private key is associated with a policy over these attributes. (In academic literature, this variant is sometimes referred to as "Key-Policy" ABE.)
For example, a company could automatically encrypt all of its emails with the attributes being some (or all) of the 75 fields in Mail headers and then later the company can distribute a key to an analyst that allows for decryption of all emails that meet the policy of To:engineering@corporation.com OR (subject contains cascade project AND sent between Dec 21, 2017 and Jan 10, 2018.
Role-based Access Control - for policies known at the time of encryption (e.g., classified documents, medical records).
An ABE system for role-based access control "flips" the semantics of content-based access control. In such a system, attributes are associated with a private key and a policy (or boolean formula) is associated with the ciphertext. Here the attributes are often be associated with the credentials of a private key holder. (In academic literature this variant is sometimes referred to as "Ciphertext-Policy" ABE.) For instance, one could restrict a ciphertext only to female employees who have been with the company since 2012 and worked on the "HALE" software project.
Multi-authority Role-based Access Control - for operating across organizational boundaries.
One issue with role-based access control is that in many applications you may need to write access control policies that span across different administrative boundaries. In standard ABE, there is one authority that hands out private keys. However, in some applications, it is natural for different authorities to manage different attributes. A multi-authority ABE system allows one to associate a ciphertext with a policy written across attributes issued by different authorities. These authorities can operate independently and do not have to coordinate (or even be aware of) each other.
For instance, the government might certify the attributes in a person's driver's license (such as age), while a credit score company could distribute credentials about a user's credit score and an employer could distribute credentials about its employees. With this type of ABE, one can now send out a special offer readable by anyone over age 50 with a strong credit score and a job at a local employer.
OpenABE is a C/C++ software library offering several attribute-based encryption (ABE) schemes together with other core cryptographic functionalities such as authenticated symmetric-key encryption, public key encryption, digital signatures, X.509 certificate handling, key derivation functions, pseudorandom generators and more.
For the full cryptographic technical details inside OpenABE, see the included OpenABE Design Document.
Application developers should not need to be cryptographic experts to use ABE. To make OpenABE as secure and user-friendly as possible, the following features are provided by default:
OpenABE comes with support for efficient and optimized implementations of content-based and role-based ABE schemes.
For the full cryptographic technical details inside OpenABE, see the included OpenABE Design Document.
Currently, OpenABE can be installed in the following environments:
This section describes the installation of the OpenABE source code (libopenabe-1.0.0-src.tar.gz) on various platforms. The OpenABE currently supports several operating systems including multiple versions/distros of Linux, Mac OS X and Windows.
To compile OpenABE on Ubuntu or Debian Linux-based distro, first run the deps/install_pkgs.sh script from the source directory to install the OpenABE system-specific dependencies as follows:
cd libopenabe-1.0.0/
sudo -E ./deps/install_pkgs.sh
Note that you only have to do this once per system setup. After completion, you can proceed to compile the OpenABE as follows:
. ./env
make
make test
All the unit tests should pass at this point and you can proceed to install the OpenABE in a standard location (/usr/local) as follows:
sudo -E make install
To change the installation path prefix, modify the INSTALL_PREFIX variable in libopenabe-1.0.0/Makefile.
As before, first run the script from the source directory to setup OpenABE dependencies:
cd libopenabe-1.0.0/
sudo ./deps/install_pkgs.sh
scl enable devtoolset-3 bash
Note that you only have to do this once per system setup. After completion, you can proceed to compile the OpenABE as follows:
. ./env
make
make test
All the unit tests should pass at this point and you can proceed to install the OpenABE in a standard location (/usr/local) as follows:
sudo make install
To change the installation path prefix, modify the INSTALL_PREFIX variable in libopenabe-1.0.0/Makefile.
Note that for Mac OS X, you will need homebrew installed prior to running the deps/install_pkgs.sh script. Then, do the following (you may require sudo on the second step):
cd libopenabe-1.0.0/
./deps/install_pkgs.sh
Note that you only have to do this once per system setup. After completion, you can proceed to compile the OpenABE as follows:
. ./env
make
make test
All the unit tests should pass at this point and you can proceed to install the OpenABE in a standard location (/usr/local) as follows:
sudo -E make install
To change the installation path prefix, modify the INSTALL_PREFIX variable in libopenabe-1.0.0/Makefile.
To build OpenABE on Windows 7, 8, and 10, you will need to download and install Mingw-w64,
the GNU toolchain port for building Windows-native binaries. We use the Mingw-w64 port packaged
with Minimal SYStem 2 (MSYS2). MSYS2 is an emulated POSIX-compliant environment for building
software with GNU tooling (e.g., GCC), bash, and package management using Arch Linux's Pacman.
Binaries compiled with these compilers do not require cygwin.dll as they are standalone.
Download msys2-x86_64-latest.exe and run it. Select C:\ for the installation directory to avoid PATH resolution problems.
Launch the MSYS2 shell and execute the following command:
update-core
Close the MSYS2 shell and launch the MinGW-w64 Win64 Shell. Note that after starting MSYS2, the prompt will indicate which version you have launched.
Update the pre-installed MSYS2 packages (and install related tooling), close the shell when prompted to, and relaunch the MinGW-w64 Win64 Shell. Execute the following command to start the process:
pacman -Sy
pacman -Su base-devel unzip git wget mingw-w64-i686-toolchain \
mingw-w64-x86_64-toolchain mingw-w64-i686-cmake mingw-w64-x86_64-cmake
Install the required third-party libraries by executing the following command:
pacman -S gmp-devel mingw-w64-i686-boost mingw-w64-x86_64-boost \
mingw-w64-x86_64-gtest mingw-w64-i686-gtest
In the libopenabe directory, execute the following:
. ./env
make
make test
If all the unit tests pass, then proceed to install the library in a standard location:
make install
To build OpenABE for Android, you will need to download and install the Android NDK. The NDK is a toolset that enables cross-compiling C and C++ for ARM and Android-specific libraries and implementations of standard libraries (e.g., GNU STL). We use Android NDK r10e and build on Debian 7.
Download the Android NDK r10e at the following links:
Unzip the NDK to a directory of your choice. We unzip it to /opt/android-ndk-r10e/ and will refer to this as $ANDROID_NDK_ROOT hereafter.
We build all libraries outside of the OpenABE deps directory. We export the following variables to streamline and contain the build process with a standalone toolchain:
export TOOLCHAIN_ARCH=arm-linux-androideabi-4.8
export MIN_PLATFORM=android-14
export INSTALLDIR=$HOME/android
With these variables set, you can now make the stan