<commit_before>---
title:             "Interlok + AWS KMS"
description:       "Fun and games with AWS KMS interoperability"
published:         true
categories:        [interlok, aws]
tags:              [interlok, aws]
author:            [quotidian-ennui]
keywords:          "interlok, aws, kms, encrypt, decrypt, sign, verify, public key, private key, cryptography, bouncy castle"
excerpt_separator: <!-- more -->
---

As of 3.10.1 (the next release due Q2 2020); there is support for AWS KMS within Interlok for their key operations, namely encryption; decryption; signing; and signature verification. The AWS SDK is very easy to use, so producing the code itself didn't take long; it took longer to write the unit tests as usual. When writing a new optional component, we normally make the decision that we expose the configuration to the user, so the user can decide how they want to interact with the system.

<!-- more -->

While KMS abstracts a lot of the complexity for you, cryptography is _hard to get right_; that means we as integration specialists need to understand at a non-superficial level a lot of the technologies and what tools we can use to investigate and debug. I'm going to focus on the signing / signature verification since this is most relevant to the use-case that we're doing.

KMS is pure key management; by this I mean you have public and private keys (if you're using asymmetric operations) but no concept of X.509 certificates or similar (this becomes important a bit later). Any asymmetric operations you do via KMS assume that you have access to both the public + private key; this means that your customer managed key cannot _just be the public key_. This then has a cascading effect because if you want to verify a document from your business partner; you will only have access to their public key, which means that you can't use KMS to do signature verification.

Our use case is pretty simple it's basically :

1. Create a digital signature of a document.
1. Send the document to a REST endpoint; along with the signature.
1. Receive a document via a webhook
1. Verify the signature of the document.


However, of course, the devil is in the details; and we faced a few problems on the way.

## Getting the public key to our partner.
<commit_msg>Pictures<commit_after>---
title:             "Interlok + AWS KMS"
description:       "Fun and games with AWS KMS interoperability"
published:         true
categories:        [interlok, aws]
tags:              [interlok, aws]
author:            [quotidian-ennui]
keywords:          "interlok, aws, kms, encrypt, decrypt, sign, verify, public key, private key, cryptography, bouncy castle"
billboard: /billboards/icon-open-source.png
excerpt_separator: <!-- more -->
---

As of 3.10.1 (the next release due Q2 2020); there is support for AWS KMS within Interlok for their key operations, namely encryption; decryption; signing; and signature verification. The AWS SDK is very easy to use, so producing the code itself didn't take long; it took longer to write the unit tests as usual. When writing a new optional component, we normally make the decision that we expose the configuration to the user, so the user can decide how they want to interact with the system.

<!-- more -->

While KMS abstracts a lot of the complexity for you, cryptography is _hard to get right_; that means we as integration specialists need to understand at a non-superficial level a lot of the technologies and what tools we can use to investigate and debug. I'm going to focus on the signing / signature verification since this is most relevant to the use-case that we're doing.

KMS is pure key management; by this I mean you have public and private keys (if you're using asymmetric operations) but no concept of X.509 certificates or similar (this becomes important a bit later). Any asymmetric operations you do via KMS assume that you have access to both the public + private key; this means that your customer managed key cannot _just be the public key_. This then has a cascading effect because if you want to verify a document from your business partner; you will only have access to their public key, which means that you can't use KMS to do signature verification.

Our use case is pretty simple it's basically :

1. Create a digital signature of a document.
1. Send the document to a REST endpoint; along with the signature.
1. Receive a document via a webhook
1. Verify the signature of the document.


However, of course, the devil is in the details; and we faced a few problems on the way.

## Getting the public key to our partner.

{'fraction_non_alphanumeric': 0.05122639461688735, 'fraction_numerical': 0.006945951812459301, 'mean_word_length': 3.721311475409836, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6021249', 'n_tokens_mistral': 1162, 'n_tokens_neox': 1114, 'n_words': 726}