loader from loading.io

Bill Buchanan - A Bluffer’s Guide To Encryption In The Cloud: Top 100

ASecuritySite Podcast

Release Date: 08/21/2023

World-leaders in Cryptography: Leslie Lamport show art World-leaders in Cryptography: Leslie Lamport

ASecuritySite Podcast

Please excuse the poor quality of my microphone, as the wrong microphone was selected.   In research, we are all just building on the shoulders of true giants, and there are few larger giants than Leslie Lamport — the creator of LaTeX. For me, every time I open up a LaTeX document, I think of the work he did on creating LaTeX, and which makes my research work so much more productive. If I was still stuck with Microsoft Office for research, I would spend half of my time in that horrible equation editor, or in trying to integrate the references into the required format, or in...

info_outline
World-leaders in Cryptography: Daniel J Bernstein show art World-leaders in Cryptography: Daniel J Bernstein

ASecuritySite Podcast

Daniel J Bernstein (djb) was born in 1971. He is a USA/German citizen and a Personal Professor at Eindhoven University of Technology and a Research Professor at the University of Illinois at Chicago. At the tender age of 24 — in 1995 — he, along with the Electronic Frontier Foundation — brought a case against the US Government related to the protection of free speech (Bernstein v. United States: ). It resulted in a ruling that software should be included in the First Amendment. A core contribution is that it has reduced government regulations around cryptography. It was a sign of the...

info_outline
World-leaders in Cryptography: Jan Camenisch show art World-leaders in Cryptography: Jan Camenisch

ASecuritySite Podcast

Jan is the CTO and a Cryptographer at DFINITY, and, since 1998, he has consistently produced research outputs of rigour, novelty and sheer brilliance [here]. He was recently awarded the Levchin Prize at Real World Crypto 2024 - along with Anna Lysyanskaya. Jan’s research core happened when he was hosted in the IBM Zurich Research Lab, but has since moved to DFINITY, and is still producing research outputs that are some of the best in the whole of the computer science research area. He has published over 140 widely cited papers and has been granted around 140 patents. Jan has also received...

info_outline
An Interview with Ted Miracco show art An Interview with Ted Miracco

ASecuritySite Podcast

Ted Miracco is the CEO of Approov and which is Scottish/US company that is headquartered in Edinburgh. Miracco has over 30 years of experience in cybersecurity, defence electronics, RF/microwave circuit design, semiconductors and electronic design automation (EDA). He co-founded and served as CEO of Cylynt, which focuses on intellectual property and compliance protection

info_outline
World-leaders in Cybersecurity: Troy Hunt show art World-leaders in Cybersecurity: Troy Hunt

ASecuritySite Podcast

Troy is a world-leading cybersecurity professional. He created and runs the Have I Been Pwned? Web site, and which contains details of the most significant data breaches on the Internet.  Along with this, he has developed other security tools, such as ASafaWeb, which automated the security analysis of ASP.NET Web sites. Troy is based in Australia and has an extensive blog at

info_outline
The Greatest Step Change in Cybersecurity Ever! Welcome to the New and Scary World of Generative AI and Cybersecurity show art The Greatest Step Change in Cybersecurity Ever! Welcome to the New and Scary World of Generative AI and Cybersecurity

ASecuritySite Podcast

This is Day 0 of a new world of cybersecurity. Everything changes from here. There will be a time before Generative AI (GenAI) in cybersecurity and a time after it. Over the last two years, GenAI has come on leaps and bounds, and where it once suffered from hallucinations, took racist and bigoted approaches, and often was over-assertive, within ChatGPT 4.5, we see the rise of a friendly and slightly submissive agent, and that is eager to learn from us. This LLM (Large Language Model) approach thus starts to break down the barriers between humans and computers and brings the opportunity to gain...

info_outline
Towards the Memex: All Hail The Future Rulers of our World show art Towards the Memex: All Hail The Future Rulers of our World

ASecuritySite Podcast

And, so George Orwell projected a world where every single part of our lives was monitored and controlled by Big Brother. Arthur C Clark outlined the day when machines focused solely on a goal — even if it was to the detriment of human lives. And, Isaac Asimov outlined a world where machines would have to be programmed with rules so that they could not harm a human. The Rise of the Machine With the almost exponential rise in the power of AI, we are perhaps approaching a technological singularity — a time when technological growth becomes uncontrollable and irreversible, and which can have...

info_outline
World-leaders in Cryptography: Marty Hellman (March 2024) show art World-leaders in Cryptography: Marty Hellman (March 2024)

ASecuritySite Podcast

This seminar series runs for students on the Applied Cryptography and Trust module, but invites guests from students from across the university. Martin is one of the co-creators of public key encryption, and worked alongside Whitfield Diffie in the creation of the widely used Diffie-Hellman method. In 2015, he was presented with the ACM Turing Award (the equivalent of a Nobel Prize in Computer Science) for his contribution to computer science. He is currently a professor emeritus at Stanford University. https://engineering.stanford.edu/node/9141/printable/print  

info_outline
World-leaders in Cryptography: Vincent Rijmen (March 2024) show art World-leaders in Cryptography: Vincent Rijmen (March 2024)

ASecuritySite Podcast

Vincent Rijmen is one of the co-creators of the NIST-defined AES standard (also known as Rijndael). He also co-designed the WHIRLPOOL hashing method, along with designing other block ciphers, such as Square and SHARK. In 2002, Vincent was included in the Top 100 innovators in the world under the age of 35, and, along with Joan Daemen, was awarded the RSA Award for Excellence in Mathematics. He recently joined Cryptomathic as a chief cryptographer, and also holds a professor position (gewoon hoogleraar) at K.U.Leuven, and adjunct professorship at the University of Bergen, Norway. His paper on...

info_outline
World-leaders in Cryptography: Whitfield Diffie show art World-leaders in Cryptography: Whitfield Diffie

ASecuritySite Podcast

Whitfield Diffie is one of the greatest Computer Scientists ever. He - along with Marty Hellman - was one of the first to propose the usage of public key encryption and co-created the Diffie-Hellman (DH) key exchange method. Overall, the Diffie-Hellman method is still used in virtually every Web connection on the Internet, and has changed from using discrete log methods to elliptic curve methods. In 2015, Whitfield was also awarded the ACM Turing Prize - and which is the Nobel Prize equivalent in Computer Science.  In this on-line talk he meets with Edinburgh Napier University students,...

info_outline
 
More Episodes

In cybersecurity, the teaching of Cloud security is often weak. So, here are my Top 100 things about encryption in the Cloud. I’ve focused on AWS, but Azure is likely to also be applicable.

  1. Keys are created in the AWS KMS (Key Management Store). In Azure, this is named KeyVault.
  2. The cost of using a key in KMS is around $1/month (prorated hourly). When a key is disabled, it is not charged.
  3. With AWS KMS, we use a shared customer HSM (Hardware Security Module), and with AWS CloudHSM it is dedidated to one customer.
  4. For data at rest, with file storage, we can integrate encryption with Amazon EBS (Elastic Block Storage) and Amazon S3.
  5. Amazon EBS drives are encrypted with AES-256 with XTS mode.
  6. For AWS-managed keys, a unique key is used for every object within S3 buckets.
  7. Amazon S3 uses server-side encryption to store encrypted data. The customer can use client-side encryption to encrypt data before it is stored in the AWS infrastructure.
  8. AWS uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) for its symmetric key encryption.
  9. In AWS S3, by default, all the objects are encrypted.
  10. A customer can use client-side encryption to encrypt data before it goes into the AWS infrastructure.
  11. For data at rest, for databases, we can integrate encryption with Amazon RDS (AWS’s relational database service) and Amazon Redshift (AWS’s data warehousing).
  12. For data at rest, we can integrate encryption into ElastiCache (AWS’s content caching service), AWS Lambda (AWS’s serverless computing service), and Amazon SageMake (AWS’s machine learning service).
  13. Keys are tokenized and have an ARN (Amazon Resource Names) and alias. An example ARN for a key is arn:aws:kms:us-east-1:103269750866:key/de30e8e6-c753–4a2c-881a-53c761242644, and an example alias is “Bill’s Key”. Both of these should be unique in the user’s account.
  14. To define a KMS key, we can either use its key ID, its key ARN, its alias name, or alias ARN.
  15. You can link keys to other AWS Accounts. For this, we specify in the form of “arn:aws:iam::[AWS ID]:root”, and where AWS ID is the ID of the other AWS account.
  16. To enhance security, we can use AWS CloudHSM (Hardware Security Module). For simpler and less costly solutions, we typically use AWS KMS (Key Management Solution). For CloudHSM, we pay per hour, but for KMS, we just pay for the usage of the keys.
  17. The application of the keys is restricted to defined services.
  18. Key identifiers and policies are defined with a JSON key-value pair for data objects.
  19. Each key should have a unique GUID, such as “de30e8e6-c753–4a2c-881a-53c761242644”.
  20. Users are identified and roles are identified with an ARN, such as : “arn:aws:iam::222222:root”.
  21. With the usage of keys we have Key Administrative Permission and a Key Usage policies.
  22. There is an explicit denial on a policy if there is not a specific allow defined in a policy.
  23. For key permissions, we have fields of “Sid” (the descriptive name of the policy), “Effect” (typically “Allow”), Principal (the ARN of the user/group), “Action” (such as Create, Disable and Delete) and “Resource”. A wildcard (“*”) allows or disallows all.
  24. To enable a user of “root” access to everything with a key would be : “Sid”: “Enable IAM User Permissions”, “Effect”: “Allow”,“Principal”: {“AWS”: “arn:aws:iam::22222222:root”},“Action”: “kms:*”, “Resource”: “*”}.
  25. The main operations within the KMS are to encrypt/decrpyt data, sign/verify signatures, export data keys, and generate/verify MACs (Message Authentication Codes).
  26. Key are either AWS managed (such as for the Lambda service), Customer managed keys (these are created and managed by the customer).
  27. Custom key stores are where the customer has complete control over the keys).
  28. The main use of keys are for EC2 (Compute), EBS (Elastic Block Storage) and S3 (Storage).
  29. AES symmetric keys or an RSA key pair are used to encrypt and decrypt.
  30. RSA uses 2K, 3K or 4K keys, and with either “RSA PCKS1 v1.5” or “RSA PSS” padding.
  31. RSA PCKS1 v1.5 padding is susceptible to Bleichenbacher’s attack, so it should only be used for legacy applications, and for all others, we should use RSA PSS.
  32. For RSA, we can use a hashing method of SHA-256, SHA-384 or SHA-512.
  33. In RSA, we encrypt with the public key and decrypt with the private key.
  34. For signatures, we can use either RSA or ECC signing. For RSA, we have 2K, 3K, or 4K keys, whereas ECC signing uses NIST P256, NIST P384, NIST P521, and SECG P256k1 (as used in Bitcoin and Ethereum).
  35. For MACs (Message Authentication Codes), Bob and Alice have the same shared secret key and can authenticate the hash version of a message. In the KMS, we can have HMAC-224, HMAC-256, HMAC-384 and HMAC-512.
  36. KMS uses hardware security modules (HSMs) with FIPS 140–2 and which cannot be accessed by AWS employees (or any other customer).
  37. Keys will never appear in an AWS disk or backup, and only existing the memory of the HSM. They are only loaded when used.
  38. Encryption keys can be restricted to one region of the world (unless defined by the user).
  39. With symmetric keys, the key never appears outside the HSM, and for asymmetric keys (public key encryption), the private key stays inside the HSM, and only the public key is exported outside.
  40. AWS CloudWatch shows how and when the encryption keys are being used.
  41. The minimum time that can be set for a key to be deleted is seven days (and up to 30 days maximum).
  42. An organisation can also create its own HSM with the CloudHSM cluster. When a key is then created in KMS, it is then stored in the cluster.
  43. The usage of encryption keys should be limited to a minimal set of service requirements.
  44. If possible, separate key managers and key users.
  45. With a key management (KEY_ADMINISTRATOR) role, we typically have the rights to create, revoke, put, get, list and disable keys. The key management role will typically not be able to encrypt and decrypt.
  46. For a key user (KEY_WORKER) role, we cannot create or delete keys and typically focus on tasks such as encrypting and decrypting.
  47. Hae a rule of minimum access rights, and simplify user access by defining key administration and usage roles. Users are then added to these roles.
  48. Avoid manual updates to keys and use key rotation. The system keeps track of keys that are rotated and can use previously defined ones.
  49. The default time to rotate keys is once every year.
  50. Key rotation shows up in the CloudWatch and CloudTrail logs.
  51. KMS complies with PCI DSS Level 1, FIPS 140–2, FedRAMP, and HIPAA.
  52. AWS KMS is matched to FIPS 140–2 Level 2.
  53. AWS CloudHSM complies with FIPS 140–2 Level 3 validated HSMs.
  54. AWS CloudHSM costs around $1.45 per hour to run, and the costs end when it is disabled or deleted.
  55. The CloudHSM is backed-up every 24 hours, and where we can cluster the HSMs into a single logical HSM.
  56. CloudHSM can be replicated in AWS regions.
  57. AWS KSM is limited to the popular encryption methods, whereas the CloudHSM can implement a wider range of methods.
  58. The CloudHSM can support methods such as 3DES with AWS Payment Cryptography. This complies with payment card industry (PCI) standards, such as PCI PIN, PCI P2PE, and PCI DSS.
  59. In the CloudHSM for payments, we can generate CVV, CVV2 and ARQC values, and where sensitive details never exist outside the HSM in an unprotected form.
  60. With the CloudHSM, we have a command line interface where we can issue commands, and is named CloudHSM CLI.
  61. Within the CloudHSM CLI, we can use the genSymKey command to generate symmetric key within the HSM, such as where -t is a key type (31 is AES), -s is a key size (32 bytes) and -l is the label:
    genSymKey -t 31 -s 32 -l aes256
  62. With genSymKey the key types are: 16 (Generic Secret), 18 (RC4), 21 (Triple DES), and 31 (AES).
  63. Within the CloudHSM CLI, we can use the genRSAKeyPair command to generate an RSA key pair, such as where -m is the modulus and -e is the public exponent:
    genRSAKeyPair -m 2048 -e 65537 -l mykey
  64. AWS CloudHSM is integrated with AWS CloudTrail, and where we can track user, role, or an AWS service within AWS CloudHSM.
  65. With AWS Payments Cryptography, the 2KEY TDES is Two-key Triple DES and has a 112-bit equivalent key size.
  66. The Pin Encryption Key (PEK) is used to encryption PIN values and uses a KEY TDES key. This can store PINs in a secure way, and then decrypt them when required.
  67. S3 buckets can be encrypted either with Amazon S3-managed keys (SSE-S3) or AWS Key Management Service (AWS KMS) keys.
  68. There is no cost to use SSE keys.
  69. For symmetric key encryption, AWS uses envelope encryption, and where a random key is used to encrypt data, and then the key is encrypted with the user’s key. AWS should not be able to access the key used for the encryption.
  70. The default in creating an encryption key is for it only be to used in a single region, but this can be changed to multi-region, and where the key will be replicated across more than one region.
  71. In AWS, a region is a geographical area, and which is split into isolated locations. US-East-1 (N.Virginia) and US-East-2 (Ohio) are different regions, while us-east-1a, us-east-1b and us-east-1c are in the same region. A single region key the US-East-1 region would replicate across eu-east-1a, eu-east-1b and eu-east-1c, and not to eu-east-2a, eu-east-2b and eu-east-2c.
  72. When creating a key, you can either create in the KMS, import a key (BYOK — bring your own key), create in the AWS CloudHSM, or create in an external key store (HYOK — hold you own key).
  73. For keys stored on-premise we can use an external key store (XKS) — this can be defined as Hold Your Own Keys (HYOKs), and where and where no entity in AWS will able to read any of the encrypted data. [here].
  74. You can BYOK (bring your own key) with KMS, and import keys. KMS will keep a copy of this key.
  75. With XKS, we need a proxy URI endpoint, with the proxy credentials of an access key ID, and secret access key.
  76. To export keys from AWS CloudHSM, we can encrypt them with an AES key. This is known as key wrapping, as defined in RFC 5648 (for padding with zeros) or RFC 3394 (without padding).
  77. A strong password should always be used for key wrapping.
  78. AWS encryption operations can either be conducted from the command line or within API, such as with Python, Node.js or Golang.
  79. With KMS, the maximum data size is 4,096 bytes for a symmetric key, 190 bytes for RSA 2048 OAEP SHA-256, 318 bytes for RSA 3072 OAEP SHA-256, ad 446 bytes for RSA 4096 OAEP SHA-256.
  80. An example command to encrypt a file for 1.txt with symmetric key encryption is:
    aws kms encryp --key-id alias/MySymKey --plaintext fileb://1.txt --query CiphertextBlob --output text > 1.out
  81. To decrypt a file with symmetric key encryption, an example with 1.enc is:
    aws kms decrypt --key-id alias/BillsNewKey --output text --query Plaintext --ciphertext-blob fileb://1.enc > 2.out
  82. In Python, to integrate with KMS, we use the Boto3 library.
  83. The standard output of encrypted content is in byte format. If we need to have a text version of ciphertext, we typically use Base64 format.
  84. The base64 command can be used to convert byte format in Base64, such as with:
    $ base64 -i 1.out — decode > 1.enc
  85. The xxd command in the command line allows the cipher text to be dumped to a hex output and can then be edited. We can then convert it back to a binary output with:
  86. An example piece of Python code for encrypting a plaintext message with the symmetric key in Python is:
    ciphertext = kms_client.encrypt(KeyId=alias,Plaintext=bytes(secret, encoding=’utf8')
  87. An example piece of Python code to decrypt some cipher text (in Base64 format) is:
    plain_text = kms_client.decrypt(KeyId=alias,CiphertextBlob=bytes(base64.b64decode(ciphertext)))
  88. To generate an HMAC signature for a message in the command line, we have the form of:
    aws kms generate-mac --key-id alias/MyHMACKey --message fileb://1.txt --mac-algorithm HMAC_SHA_256 --query Mac > 4.out
  89. To verify an HMAC signature for a message in the command line, we have the form of:
    aws kms verify-mac -key-id alias/MyHMACKey -message fileb://1.txt \
    -mac-algorithm HMAC_SHA_256 -mac fileb://4.mac
  90. To create an ECDSA signature in the command line, we have the form of:
    aws kms sign -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signing-algorithm ECDSA_SHA_256 -query Signature > 1.out
  91. To verify an ECDSA signature in the command line, we have the form of:
    aws kms verify -key-id alias/MyPublicKeyForSigning -message fileb://1.txt -signature fileb://1.sig -signing-algorithm ECDSA_SHA_256
  92. To encrypt data using RSA in the command line, we have the form of:
    aws kms encrypt -key-id alias/PublicKeyForDemo -plaintext fileb://1.txt -query CiphertextBlob -output text -encryption-algorithm RSAES_OAEP_SHA_1 > 1.out
  93. To decrypt data using RSA in the command line, we have the form of:
    aws kms decryptb -key-id alias/PublicKeyForDemo -output text -query Plaintext -ciphertext-blob fileb://1.enc -encryption-algorithm RSAES_OAEP_SHA_1 > 2.out
  94. To sign data using RSA in the command line, we have the form of:
    aws kms sign --key-id alias/MyRSAKey --message fileb://1.txt --signing-algorithm RSASSA_PSS_SHA_256 --query Signature --output text > 1.out
  95. To verify data using RSA in the command line, we have the form of:
    aws kms verify --key-id alias/MyRSAKey --message fileb://1.txt — signature fileb://1.sig --signing-algorithm RSASSA_PSS_SHA_256
  96. You cannot encrypt data with Elliptic Curve keys. Only RSA and AES can do that. Elliptic Curve keys are used to sign data.
  97. If you delete an encryption key, you will not be able to decrypt any ciphertext that uses it.
  98. We can store our secrets, such as application passwords, in the secrets manager. An example of a secret name of “my-secret-passphrase” and a secret string of “Qwery123” we can have:
    aws secretsmanager create-secret --name my-secret-passphrase
    --secret-string Qwerty123
  99. In China regions, along with RSA and ECDSA, you can use SM2 KMS signing keys.
  100. In China Regions, we can use SM2PKE to encrypt data with asymmetric key encryption.

Find out more here:

https://asecuritysite.com/aws