9afbfdc833
First deal with deleted files. * Files deleted by us: keep them deleted. * Files deleted by them, whether modified by us or not: keep our version. ``` git rm $(git status -s | sed -n 's/^DU //p') git reset -- $(git status -s | sed -n 's/^D //p') git checkout -- $(git status -s | sed -n 's/^ D //p') git add -- $(git status -s | sed -n 's/^UD //p') ``` Individual files with conflicts: * `3rdparty/everest/library/Hacl_Curve25519_joined.c`: spurious conflict because git mistakenly identified this file as a rename. Keep our version. * `README.md`: conflict due to their change in a paragraph that doesn't exist in our version. Keep our version of this paragraph. * `docs/architecture/Makefile`: near-identical additions. Adapt the definition of `all_markdown` and include the clean target. * `doxygen/input/docs_mainpage.h`: conflict in the version number. Keep our version number. * `include/mbedtls/config.h`: two delete/modify conflicts. Keep the removed chunks out. * `library/CMakeLists.txt`: discard all their changes as they are not relevant. * `library/Makefile`: * Discard the added chunk about the crypto submodule starting with `INCLUDING_FROM_MBEDTLS:=1`. * delete/modify: keep the removed chunk out. * library build: This is almost delete/modify. Their changes are mostly not applicable. Do keep the `libmbedcrypto.$(DLEXT): | libmbedcrypto.a` order dependency. * `.c.o`: `-o` was added on both sides but in a different place. Change to their place. * `library/error.c`: to be regenerated. * `library/version_features.c`: to be regenerated. * `programs/Makefile`: Most of the changes are not relevant. The one relevant change is in the `clean` target for Windows; adapt it by removing `/S` from our version. * `programs/test/query_config.c`: to be regenerated. * `scripts/config.py`: added in parallel on both sides. Keep our version. * `scripts/footprint.sh`: parallel changes. Keep our version. * `scripts/generate_visualc_files.pl`: one delete/modify conflict. Keep the removed chunks out. * `tests/Makefile`: discard all of their changes. * `tests/scripts/all.sh`: * `pre_initialize_variables` add `append_outcome`: add it. * `pre_initialize_variables` add `ASAN_CFLAGS`: already there, keep our version. * `pre_parse_command_line` add `--no-append-outcome`: add it. * `pre_parse_command_line` add `--outcome-file`: add it. * `pre_print_configuration`: add `MBEDTLS_TEST_OUTCOME_FILE`. * Several changes in SSL-specific components: keep our version without them. * Several changes where `config.pl` was changed to `config.py` and there was an adjacent difference: keep our version. * Changes regarding the inclusion of `MBEDTLS_MEMORY_xxx`: ignore them here, they will be normalized in a subsequent commit. * `component_test_full_cmake_gcc_asan`: add it without the TLS tests. * `component_test_no_use_psa_crypto_full_cmake_asan`: keep the fixed `msg`, discard other changes. * `component_test_memory_buffer_allocator_backtrace`, `component_test_memory_buffer_allocator`: add them without the TLS tests. * `component_test_m32_everest`: added in parallel on both sides. Keep our version. * `tests/scripts/check-names.sh`, `tests/scripts/list-enum-consts.pl`, `tests/scripts/list-identifiers.sh`, ``tests/scripts/list-macros.sh`: discard all of their changes. * `tests/scripts/test-ref-configs.pl`: the change in the conflict is not relevant, so keep our version there. * `visualc/VS2010/*.vcxproj`: to be regenerated. Regenerate files: ``` scripts/generate_visualc_files.pl git add visualc/VS2010/*.vcxproj scripts/generate_errors.pl git add library/error.c scripts/generate_features.pl git add library/version_features.c scripts/generate_query_config.pl git add programs/test/query_config.c ``` Rejected changes in non-conflicting files: * `CMakeLists.txt`: discard their addition which has already been side-ported. * `doxygen/mbedtls.doxyfile`: keep the version number change. Discard the changes related to `../crypto` paths. Keep the following changes after examination: * `.travis.yml`: all of their changes are relevant. * `include/mbedtls/error.h`: do keep their changes. Even though Crypto doesn't use TLS errors, it must not encroach on TLS's allocated numbers. * `tests/scripts/check-test-cases.py`: keep the code dealing with `ssl-opt.sh`. It works correctly when the file is not present. |
||
---|---|---|
.github | ||
3rdparty | ||
configs | ||
docs | ||
doxygen | ||
include | ||
library | ||
programs | ||
scripts | ||
tests | ||
visualc/VS2010 | ||
.gitignore | ||
.globalrc | ||
.pylintrc | ||
.travis.yml | ||
apache-2.0.txt | ||
CMakeLists.txt | ||
CONTRIBUTING.md | ||
DartConfiguration.tcl | ||
LICENSE | ||
Makefile | ||
README.md |
Mbed Crypto library
The Mbed cryptography library is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This is a preview release of Mbed Crypto, provided for evaluation purposes only.
Mbed Crypto is distributed under the Apache License, version 2.0. See the LICENSE file for the full text of the license.
PSA cryptography API
Arm's Platform Security Architecture (PSA) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.
The PSA cryptography API provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.
The design goals of the PSA cryptography API include:
- The API distinguishes caller memory from internal memory, which allows the library to be implemented in an isolated space for additional security. Library calls can be implemented as direct function calls if isolation is not desired, and as remote procedure calls if isolation is desired.
- The structure of internal data is hidden to the application, which allows substituting alternative implementations at build time or run time, for example, in order to take advantage of hardware accelerators.
- All access to the keys happens through handles, which allows support for external cryptoprocessors that is transparent to applications.
- The interface to algorithms is generic, favoring algorithm agility.
- The interface is designed to be easy to use and hard to accidentally misuse.
Mbed Crypto implementation
Mbed Crypto is a reference implementation of the PSA cryptography API. It is written in portable C.
Documentation
The Mbed Crypto library is a reference implementation of the PSA cryptography API. Please refer to the PSA Cryptography API documents for an overview of the library's interfaces and a detailed description of the types, macros and functions that it provides.
There are currently a few deviations where the library does not yet implement the latest version of the specification. Please refer to the compliance issues on Github for an up-to-date list.
PSA Cryptography API
You can read the complete PSA cryptography API specification as a PDF document. The API reference is also available in HTML format.
Browsable library documentation
To generate a local copy of the library documentation in HTML format:
- Make sure that Doxygen is installed. We use version 1.8.11 but slightly older or more recent versions should work.
- Run
make apidoc
. - Browse
apidoc/index.html
orapidoc/modules.html
.
Compiling
You need the following tools to build the library with the provided makefiles:
- GNU Make or a build tool that CMake supports.
- A C99 toolchain (compiler, linker, archiver).
- Python 2 or Python 3 (either will work) to generate the test code.
- Perl to run the tests.
If you have a C compiler, such as GCC or Clang, just run make
in the top-level directory to build the library, a set of unit tests and some sample programs.
To select a different compiler, set the CC
variable to the name or path of the compiler and linker (default: cc
), and set AR
to a compatible archiver (default: ar
). For example:
make CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar
The provided makefiles pass options to the compiler that assume a GCC-like command-line syntax. To use a different compiler, you may need to pass different values for CFLAGS
, WARNINGS_CFLAGS
and LDFLAGS
.
To run the unit tests on the host machine, run make test
from the top-level directory. If you are cross-compiling, copy the test executable from the tests
directory to the target machine.
Compiling as a subproject
Mbed Crypto supports being built as a subproject of Mbed TLS. Mbed TLS can use Mbed Crypto for its cryptography implementation by using Mbed Crypto as a subproject.
From the Mbed TLS project repository, CMake can be invoked as follows to build Mbed TLS using Mbed Crypto's libmbedcrypto
.
mkdir cmake
cd cmake
cmake .. -DUSE_CRYPTO_SUBMODULE=1
make -j
make test
When building Mbed Crypto as a subproject of Mbed TLS, the Mbed TLS configuration file (config.h) is used, and not the Mbed Crypto configuration file.
Example programs
The programs/
subdirectory contains sample programs that use the library. Please note that the goal of these sample programs is to demonstrate specific features of the library, and the code may need to be adapted to build a real-world application.
Upcoming features
Future releases of this library will include:
- A driver programming interface, which makes it possible to use hardware accelerators instead of the default software implementation for chosen algorithms.
- Support for external keys to be stored and manipulated exclusively in a separate cryptoprocessor.
- A configuration mechanism to compile only the algorithms you need for your application.
- A wider set of cryptographic algorithms.
Feedback welcome
Arm welcomes feedback on the design of the API. If you think something could be improved, please open an issue on our Github repository. Alternatively, if you prefer to provide your feedback privately, please email us at mbed-crypto@arm.com
. All feedback received by email is treated confidentially.