swift-server/security

Native vs Non-native Framework

A straightforward solution to providing unified, cross-platform APIs is by using the same underlying security library. Below we show why it is not desirable to use user-installed or non-native libraries in our solution.

Consider OpenSSL which is a cross-platform library that works both on macOS and Linux. Apple deprecated OpenSSL as of OS X v10.7 because of lack of API compatibility across versions. Since its deprecation, users are responsible for installing and upgrading OpenSSL themselves. Users can obtain OpenSSL source code and compile it themselves (and use their own custom flags) or use third party package management tools such as homebrew or macport or download the binary themselves. The range of ways that OpenSSL can be installed on macOS results in an even larger range of OpenSSL binaries which can cause incompatibility with the calling APIs and applications. This in turn makes maintainability and correctness of the APIs much harder.

This problem is further exacerbated when we consider the lack of API compatibility of OpenSSL across versions and the fact that users are now wholey responsible for upgrades of their libraries. The timeliness of the upgrades can also affect the security of the library and any linked applications.

Native frameworks in contrast, are shipped and maintained by the OS and often tie API changes to OS versions which greatly improves maintainability of linked application.

A final motivation in using native libraries is that vendors often go through security certification processes for their own modules and therefore users can get this certification for free. In particular, many use cases that involve government or enterprise data or users, require FIPS 140 compliance or validation. FIPS is a US Government (NIST) cryptographic standard and is a requirement by most government agencies and many enterprises. The process of getting certified is hard, expensive and time consuming and is only done by vendors and large organizations.

On Linux, OpenSSL contains the OpenSSL FIPS Object Module, which is FIPS 140-2 conformance validated (not just compliant). However since OpenSSL was deprecated on macOS, Apple no longer submits OpenSSL on macOS for FIPS 140 validation and therefore OpenSSL on macOS is no longer FIPS compliant. Apple submits its own CoreCrypto and CoreCrypto Kernel for validation.

Other Security Libraries on Linux

While there are a number of alternative crypto and security libraries on Linux including LibreSSL, BoringSSL, etc., their open sourced versions are not FIPS compliant. LibreSSL for example, deliberately removed the FIPS Object Module of OpenSSL to make the library more lean and thus improve both security and performance.

Package Metadata

Repository: swift-server/security

Default branch: master

README: README.md