Tag Archives: integrit

How to Use the New AWS Encryption SDK to Simplify Data Encryption and Improve Application Availability

Post Syndicated from Greg Rubin original https://blogs.aws.amazon.com/security/post/TxGBG3U5VUS2HY/How-to-Use-the-New-AWS-Encryption-SDK-to-Simplify-Data-Encryption-and-Improve-Ap

The AWS Cryptography team is happy to announce the AWS Encryption SDK. This new SDK makes encryption easier for developers while minimizing errors that could lessen the security of your applications. The new SDK does not require you to be an AWS customer, but it does include ready-to-use examples for AWS customers.

Developers using encryption often face two problems:

How to correctly generate and use a key to encrypt data.

How to protect the key after it has been used.

The library provided in the new AWS Encryption SDK addresses the first problem by transparently implementing the low-level details using the cryptographic provider available in your development environment. The library helps address the second problem by providing intuitive interfaces to let you choose how you want to protect your keys. Developers can then focus on the cores of the applications they are building, instead of on the complexities of encryption. In this blog post, I will show you how you can use the AWS Encryption SDK to simplify the process of encrypting data and how to protect your keys in ways that help improve application availability by not tying you to a single region or key management solution.

Envelope encryption and the new SDK

An important concept to understand when using the AWS Encryption SDK is envelope encryption (also known as hybrid encryption). Different algorithms have different strengths, and no single algorithm fits every use case. For example, solutions with good key management properties (such as RSA or AWS Key Management Service [KMS]) often do not work well with large amounts of data. Envelope encryption solves this problem by encrypting bulk data with a single-use data key appropriate for large amounts of data (such as AES-GCM). Envelope encryption then encrypts that data key with a master key that uses an algorithm or other solution appropriate for key management.

Another advantage of envelope encryption is that a single message can be encrypted so that multiple recipients can decrypt it. Rather than having everyone share a key (which is usually insecure) or encrypting the entire message multiple times (which is impractical), only the data key is encrypted multiple times by using each recipient’s keys. This significantly reduced amount of duplication makes encrypting with multiple keys far more practical.

The downside of envelope encryption is implementation complexity. All clients must be able to generate and parse the data formats, handle multiple keys and algorithms, and ideally remain reasonably forward and backward compatible.

How does the AWS Encryption SDK help me?

The AWS Encryption SDK comes with a carefully designed and reviewed data format that supports multiple secure algorithm combinations (with room for future expansion) and has no limits on the types or algorithms of the master keys. The AWS Encryption SDK itself is a production‑ready reference Java implementation with direct support for KMS and the Java Cryptography Architecture (JCA/JCE), which includes support for AWS CloudHSM and other PKCS #11 devices. Implementations of this SDK in other languages are currently being developed.

One benefit of the AWS Encryption SDK is that it takes care of the low-level cryptographic details so that you can focus on moving data. Next, I will show how little code you need to build a powerful and secure multiregion solution.

Example 1: Encrypting application secrets under multiple regional KMS master keys for high availability

Many customers want to build systems that not only span multiple Availability Zones, but also multiple regions. Such deployment can be challenging when data is encrypted with KMS because you cannot share KMS customer master keys (CMKs) across regions. With envelope encryption, you can work around this limitation by encrypting the data key with multiple KMS CMKs in different regions. Applications running in each region can use the local KMS endpoint to decrypt the ciphertext for faster and more reliable access.

For all examples, I will assume that I am running on Amazon EC2 instances configured with IAM roles for EC2. This lets us avoid credential management and take advantage of built-in logic that routes requests to the nearest endpoints. These examples also assume that the AWS SDK for Java (different than the AWS Encryption SDK) and Bouncy Castle are available.

The encryption logic has a very simple high-level design. After reading in some parameters from the command line, I get the master keys and use them to encrypt the file (as shown in the following code example). I will provide the missing methods later in this post.

public static void main(final String[] args) throws Exception {
// Get parameters from the command line
final String inputFile = args[0];
final String outputFile = args[1];

// Get all the master keys we’ll use
final MasterKeyProvider<?> provider = getMasterKeyProvider();

// Actually encrypt the data
encryptFile(provider, inputFile, outputFile);
}

Create master keys and combine them into a single master key provider

The following code example shows how you can encrypt data under CMKs in three US regions: us-east-1, us-west-1, and us-west-2. The example assumes that you have already set up the CMKs and created aliases named alias/exampleKey in each region for each CMK. For more information about creating CMKs and aliases, see Creating Keys in the AWS KMS documentation.

This example then uses the MultipleProviderFactory to combine all the master keys into a single master key provider. Note that the first master key is the one used to generate the new data key and the other master keys are used to encrypt the new data key.

private static MasterKeyProvider<?> getMasterKeyProvider() {
// Get credentials from Roles for EC2
final AWSCredentialsProvider creds =
new InstanceProfileCredentialsProvider();

// Get KmsMasterKeys for the regions we care about
final String aliasName = "alias/exampleKey";
final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

return MultipleProviderFactory.buildMultiProvider(
useast1, uswest1, uswest2);
}

The logic to construct a MasterKeyProvider could easily be built once by your central security team and then reused across your company to both simplify development and ensure that all encrypted data meets corporate standards.

Encrypt the data

The data you encrypt can come from anywhere and be distributed however you like. In the following code example, I am reading a file from disk and writing out an encrypted copy. The AWS Encryption SDK integrates directly with Java’s streams to make this easy.

private static void encryptFile(final MasterKeyProvider<?> provider,
final String inputFile, final String outputFile) throws IOException {
// Get an instance of the encryption logic
final AwsCrypto crypto = new AwsCrypto();

// Open the files for reading and writing
try (
final FileInputStream in = new FileInputStream(inputFile);
final FileOutputStream out = new FileOutputStream(outputFile);
// Wrap the output stream in encryption logic
// It is important that this is closed because it adds footers
final CryptoOutputStream<?> encryptingStream =
crypto.createEncryptingStream(provider, out)) {
// Copy the data over
IOUtils.copy(in, encryptingStream);
}
}

This file could contain, for example, secret application configuration data (such as passwords, certificates, and the like) that is then sent to EC2 instances as EC2 user data upon launch.

Decrypt the data

The following code example decrypts the contents of the EC2 user data and writes it to the specified file. The AWS SDK for Java defaults to using KMS in the local region, so decryption proceeds quickly without cross-region calls.

public static void main(String[] args) throws Exception {
// Get parameters from the command line
final String outputFile = args[0];

// Create a master key provider that points to the local
// KMS stack and uses Roles for EC2 to get credentials.
final KmsMasterKeyProvider provider = new KmsMasterKeyProvider(
new InstanceProfileCredentialsProvider());

// Get an instance of the encryption logic
final AwsCrypto crypto = new AwsCrypto();

// Open a stream to read the user data
// and a stream to write out the decrypted file
final URL userDataUrl = new URL("http://169.254.169.254/latest/user-data");
try (
final InputStream in = userDataUrl.openStream();
final FileOutputStream out = new FileOutputStream(outputFile);
// Wrap the input stream in decryption logic
final CryptoInputStream<?> decryptingStream =
crypto.createDecryptingStream(provider, in)) {
// Copy the data over
IOUtils.copy(decryptingStream, out);
}
}

Congratulations! You have just encrypted data under master keys in multiple regions and have code that will always decrypt the data by using the local KMS stack. This gives you higher availability and lower latency for decryption, while still only needing to manage a single ciphertext.

Example 2: Encrypting application secrets under master keys from different providers for escrow and portability

Another reason why you might want to encrypt data under multiple master keys is to avoid relying on a single provider for your keys. By not tying yourself to a single key management solution, you help improve your applications’ availability. This approach also might help if you have compliance, data loss prevention, or disaster recovery requirements that require multiple providers.

You can use the same technique demonstrated previously in this post to encrypt your data to an escrow or additional decryption master key that is independent from your primary provider. This example demonstrates how to use an additional master key, which is an RSA public key with the private key stored in a key management infrastructure independent from KMS such as an offline Hardware Security Module (HSM). (Creating and managing the RSA key pair are out of scope for this blog.)

Encrypt the data with a public master key

Just like the previous code example that created a number of KmsMasterKeys to encrypt data, the following code example creates one more MasterKey for use with the RSA public key. The example uses a JceMasterKey because it uses a java.security.PublicKey object from the Java Cryptography Extensions (JCE). The example then passes the new MasterKey into the MultipleProviderFactory (along with all the other master keys). The example loads the public key from a file called rsa_public_key.der.

private static MasterKeyProvider<?> getMasterKeyProvider()
throws IOException, GeneralSecurityException {
// Get credentials from Roles for EC2
final AWSCredentialsProvider creds =
new InstanceProfileCredentialsProvider();

// Get KmsMasterKeys for the regions we care about
final String aliasName = "alias/exampleKey";
final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
"arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

// Load the RSA public key from a file and make a MasterKey from it.
final byte[] rsaBytes = Files.readAllBytes(
new File("rsa_public_key.der").toPath());
final KeyFactory rsaFactory = KeyFactory.getInstance("RSA");
final PublicKey rsaKey = rsaFactory.generatePublic(
new X509EncodedKeySpec(rsaBytes));
final JceMasterKey rsaMasterKey =
JceMasterKey.getInstance(rsaKey, null,
"escrow-provider", "escrow",
"RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

return MultipleProviderFactory.buildMultiProvider(
useast1, uswest1, uswest2, rsaMasterKey);
}

Decrypt the data with the private key

Many HSMs support the standard Java KeyStore interface or at least supply PKCS #11 drivers, which allow you to use the existing Java KeyStore implementations. The following decryption code example uses an RSA private key from a KeyStore.

public static void main(String[] args) throws Exception {
// Get parameters from the command line
final String inputFile = args[0];
final String outputFile = args[1];

// Get the KeyStore
// In a production system, this would likely be backed by an HSM.
// For this example, it will simply be a file on disk
final char[] keystorePassword = "example".toCharArray();
final KeyStore keyStore = KeyStore.getInstance("JKS");
try (final FileInputStream fis = new FileInputStream("cryptosdk.jks")) {
keyStore.load(fis, keystorePassword);
}

// Create a master key provider from the keystore.
// Be aware that because KMS isn’t being used, it cannot directly
// protect the integrity or authenticity of this data.
final KeyStoreProvider provider = new KeyStoreProvider(keyStore,
new PasswordProtection(keystorePassword),
"escrow-provider", "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

// Get an instance of the encryption logic
final AwsCrypto crypto = new AwsCrypto();

// Open a stream to read the encrypted file
// and a stream to write out the decrypted file
try (
final FileInputStream in = new FileInputStream(inputFile);
final FileOutputStream out = new FileOutputStream(outputFile);
// Wrap the output stream in encryption logic
final CryptoInputStream<?> decryptingStream =
crypto.createDecryptingStream(provider, in)) {
// Copy the data over
IOUtils.copy(decryptingStream, out);
}
}

Conclusion

Envelope encryption is powerful, but traditionally, it has been challenging to implement. The new AWS Encryption SDK helps manage data keys for you, and it simplifies the process of encrypting data under multiple master keys. As a result, this new SDK allows you to focus on the code that drives your business forward. It also provides a framework you can easily extend to ensure that you have a cryptographic library that is configured to match and enforce your standards.

We are excited about releasing the AWS Encryption SDK and can’t wait to hear what you do with it. If you have comments about the new SDK or anything in this blog post, please add a comment in the “Comments” section below. If you have implementation or usage questions, start a new thread on the KMS forum.

– Greg

How to Use the New AWS Encryption SDK to Simplify Data Encryption and Improve Application Availability

Post Syndicated from Greg Rubin original https://blogs.aws.amazon.com/security/post/TxGBG3U5VUS2HY/How-to-Use-the-New-AWS-Encryption-SDK-to-Simplify-Data-Encryption-and-Improve-Ap

The AWS Cryptography team is happy to announce the AWS Encryption SDK. This new SDK makes encryption easier for developers while minimizing errors that could lessen the security of your applications. The new SDK does not require you to be an AWS customer, but it does include ready-to-use examples for AWS customers.

Developers using encryption often face two problems:

  1. How to correctly generate and use a key to encrypt data.
  2. How to protect the key after it has been used.

The library provided in the new AWS Encryption SDK addresses the first problem by transparently implementing the low-level details using the cryptographic provider available in your development environment. The library helps address the second problem by providing intuitive interfaces to let you choose how you want to protect your keys. Developers can then focus on the cores of the applications they are building, instead of on the complexities of encryption. In this blog post, I will show you how you can use the AWS Encryption SDK to simplify the process of encrypting data and how to protect your keys in ways that help improve application availability by not tying you to a single region or key management solution.

Envelope encryption and the new SDK

An important concept to understand when using the AWS Encryption SDK is envelope encryption (also known as hybrid encryption). Different algorithms have different strengths, and no single algorithm fits every use case. For example, solutions with good key management properties (such as RSA or AWS Key Management Service [KMS]) often do not work well with large amounts of data. Envelope encryption solves this problem by encrypting bulk data with a single-use data key appropriate for large amounts of data (such as AES-GCM). Envelope encryption then encrypts that data key with a master key that uses an algorithm or other solution appropriate for key management.

Another advantage of envelope encryption is that a single message can be encrypted so that multiple recipients can decrypt it. Rather than having everyone share a key (which is usually insecure) or encrypting the entire message multiple times (which is impractical), only the data key is encrypted multiple times by using each recipient’s keys. This significantly reduced amount of duplication makes encrypting with multiple keys far more practical.

The downside of envelope encryption is implementation complexity. All clients must be able to generate and parse the data formats, handle multiple keys and algorithms, and ideally remain reasonably forward and backward compatible.

How does the AWS Encryption SDK help me?

The AWS Encryption SDK comes with a carefully designed and reviewed data format that supports multiple secure algorithm combinations (with room for future expansion) and has no limits on the types or algorithms of the master keys. The AWS Encryption SDK itself is a production‑ready reference Java implementation with direct support for KMS and the Java Cryptography Architecture (JCA/JCE), which includes support for AWS CloudHSM and other PKCS #11 devices. Implementations of this SDK in other languages are currently being developed.

One benefit of the AWS Encryption SDK is that it takes care of the low-level cryptographic details so that you can focus on moving data. Next, I will show how little code you need to build a powerful and secure multiregion solution.

Example 1: Encrypting application secrets under multiple regional KMS master keys for high availability

Many customers want to build systems that not only span multiple Availability Zones, but also multiple regions. Such deployment can be challenging when data is encrypted with KMS because you cannot share KMS customer master keys (CMKs) across regions. With envelope encryption, you can work around this limitation by encrypting the data key with multiple KMS CMKs in different regions. Applications running in each region can use the local KMS endpoint to decrypt the ciphertext for faster and more reliable access.

For all examples, I will assume that I am running on Amazon EC2 instances configured with IAM roles for EC2. This lets us avoid credential management and take advantage of built-in logic that routes requests to the nearest endpoints. These examples also assume that the AWS SDK for Java (different than the AWS Encryption SDK) and Bouncy Castle are available.

The encryption logic has a very simple high-level design. After reading in some parameters from the command line, I get the master keys and use them to encrypt the file (as shown in the following code example). I will provide the missing methods later in this post.

public static void main(final String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get all the master keys we'll use
    final MasterKeyProvider<?> provider = getMasterKeyProvider();

    // Actually encrypt the data
    encryptFile(provider, inputFile, outputFile);
}

Create master keys and combine them into a single master key provider

The following code example shows how you can encrypt data under CMKs in three US regions: us-east-1, us-west-1, and us-west-2. The example assumes that you have already set up the CMKs and created aliases named alias/exampleKey in each region for each CMK. For more information about creating CMKs and aliases, see Creating Keys in the AWS KMS documentation.

This example then uses the MultipleProviderFactory to combine all the master keys into a single master key provider. Note that the first master key is the one used to generate the new data key and the other master keys are used to encrypt the new data key.

private static MasterKeyProvider<?> getMasterKeyProvider() {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds = 
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
                "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2);
}

The logic to construct a MasterKeyProvider could easily be built once by your central security team and then reused across your company to both simplify development and ensure that all encrypted data meets corporate standards.

Encrypt the data

The data you encrypt can come from anywhere and be distributed however you like. In the following code example, I am reading a file from disk and writing out an encrypted copy. The AWS Encryption SDK integrates directly with Java’s streams to make this easy.

private static void encryptFile(final MasterKeyProvider<?> provider,
        final String inputFile, final String outputFile) throws IOException {
    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open the files for reading and writing
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            // It is important that this is closed because it adds footers
            final CryptoOutputStream<?> encryptingStream =
                    crypto.createEncryptingStream(provider, out)) {
        // Copy the data over
        IOUtils.copy(in, encryptingStream);
    }
}

This file could contain, for example, secret application configuration data (such as passwords, certificates, and the like) that is then sent to EC2 instances as EC2 user data upon launch.

Decrypt the data

The following code example decrypts the contents of the EC2 user data and writes it to the specified file. The AWS SDK for Java defaults to using KMS in the local region, so decryption proceeds quickly without cross-region calls.

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String outputFile = args[0];

    // Create a master key provider that points to the local
    // KMS stack and uses Roles for EC2 to get credentials.
    final KmsMasterKeyProvider provider = new KmsMasterKeyProvider(
        new InstanceProfileCredentialsProvider());

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the user data
    // and a stream to write out the decrypted file
    final URL userDataUrl = new URL("http://169.254.169.254/latest/user-data");
    try (
            final InputStream in = userDataUrl.openStream();
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the input stream in decryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

Congratulations! You have just encrypted data under master keys in multiple regions and have code that will always decrypt the data by using the local KMS stack. This gives you higher availability and lower latency for decryption, while still only needing to manage a single ciphertext.

Example 2: Encrypting application secrets under master keys from different providers for escrow and portability

Another reason why you might want to encrypt data under multiple master keys is to avoid relying on a single provider for your keys. By not tying yourself to a single key management solution, you help improve your applications’ availability. This approach also might help if you have compliance, data loss prevention, or disaster recovery requirements that require multiple providers.

You can use the same technique demonstrated previously in this post to encrypt your data to an escrow or additional decryption master key that is independent from your primary provider. This example demonstrates how to use an additional master key, which is an RSA public key with the private key stored in a key management infrastructure independent from KMS such as an offline Hardware Security Module (HSM). (Creating and managing the RSA key pair are out of scope for this blog.)

Encrypt the data with a public master key

Just like the previous code example that created a number of KmsMasterKeys to encrypt data, the following code example creates one more MasterKey for use with the RSA public key. The example uses a JceMasterKey because it uses a java.security.PublicKey object from the Java Cryptography Extensions (JCE). The example then passes the new MasterKey into the MultipleProviderFactory (along with all the other master keys). The example loads the public key from a file called rsa_public_key.der.

private static MasterKeyProvider<?> getMasterKeyProvider()
      throws IOException, GeneralSecurityException {
    // Get credentials from Roles for EC2
    final AWSCredentialsProvider creds =
        new InstanceProfileCredentialsProvider();

    // Get KmsMasterKeys for the regions we care about
    final String aliasName = "alias/exampleKey";
    final KmsMasterKey useast1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-east-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest1 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-1:" + ACCOUNT_ID + ":" + aliasName);
    final KmsMasterKey uswest2 = KmsMasterKey.getInstance(creds,
            "arn:aws:kms:us-west-2:" + ACCOUNT_ID + ":" + aliasName);

    // Load the RSA public key from a file and make a MasterKey from it.
    final byte[] rsaBytes = Files.readAllBytes(
        new File("rsa_public_key.der").toPath());
    final KeyFactory rsaFactory = KeyFactory.getInstance("RSA");
    final PublicKey rsaKey = rsaFactory.generatePublic(
        new X509EncodedKeySpec(rsaBytes));
    final JceMasterKey rsaMasterKey =
        JceMasterKey.getInstance(rsaKey, null,
            "escrow-provider", "escrow",
            "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    return MultipleProviderFactory.buildMultiProvider(
        useast1, uswest1, uswest2, rsaMasterKey);
}

Decrypt the data with the private key

Many HSMs support the standard Java KeyStore interface or at least supply PKCS #11 drivers, which allow you to use the existing Java KeyStore implementations. The following decryption code example uses an RSA private key from a KeyStore.

public static void main(String[] args) throws Exception {
    // Get parameters from the command line
    final String inputFile = args[0];
    final String outputFile = args[1];

    // Get the KeyStore
    // In a production system, this would likely be backed by an HSM.
    // For this example, it will simply be a file on disk
    final char[] keystorePassword = "example".toCharArray();
    final KeyStore keyStore = KeyStore.getInstance("JKS");
    try (final FileInputStream fis = new FileInputStream("cryptosdk.jks")) {
        keyStore.load(fis, keystorePassword);
    }

    // Create a master key provider from the keystore.
    // Be aware that because KMS isn’t being used, it cannot directly
    // protect the integrity or authenticity of this data.
    final KeyStoreProvider provider = new KeyStoreProvider(keyStore,
            new PasswordProtection(keystorePassword),
            "escrow-provider", "RSA/ECB/OAEPWithSHA-256AndMGF1Padding");

    // Get an instance of the encryption logic
    final AwsCrypto crypto = new AwsCrypto();

    // Open a stream to read the encrypted file
    // and a stream to write out the decrypted file
    try (
            final FileInputStream in = new FileInputStream(inputFile);
            final FileOutputStream out = new FileOutputStream(outputFile);
            // Wrap the output stream in encryption logic
            final CryptoInputStream<?> decryptingStream =
                    crypto.createDecryptingStream(provider, in)) {
        // Copy the data over
        IOUtils.copy(decryptingStream, out);
    }
}

Conclusion

Envelope encryption is powerful, but traditionally, it has been challenging to implement. The new AWS Encryption SDK helps manage data keys for you, and it simplifies the process of encrypting data under multiple master keys. As a result, this new SDK allows you to focus on the code that drives your business forward. It also provides a framework you can easily extend to ensure that you have a cryptographic library that is configured to match and enforce your standards.

We are excited about releasing the AWS Encryption SDK and can’t wait to hear what you do with it. If you have comments about the new SDK or anything in this blog post, please add a comment in the “Comments” section below. If you have implementation or usage questions, start a new thread on the KMS forum.

– Greg

How to Help Protect Sensitive Data with AWS KMS

Post Syndicated from Matt Bretan original https://blogs.aws.amazon.com/security/post/Tx79IILINW04DC/How-to-Help-Protect-Sensitive-Data-with-AWS-KMS

AWS Key Management Service (AWS KMS) celebrated its one-year launch anniversary in November 2015, and organizations of all sizes are using it to effectively manage their encryption keys. KMS also successfully completed the PCI DSS 3.1 Level 1 assessment as well as the latest SOC assessment in August 2015.

One question KMS customers frequently ask is about how how to encrypt Primary Account Number (PAN) data within AWS because PCI DSS sections 3.5 and 3.6 require the encryption of credit card data at rest and has stringent requirements around the management of encryption keys. One KMS encryption option is to encrypt your PAN data using customer data keys (CDKs) that are exportable out of KMS. Alternatively, you also can use KMS to directly encrypt PAN data by using a customer master key (CMK). In this blog post, I will show you how to help protect sensitive PAN data by using KMS CMKs.

The use of a CMK to directly encrypt data removes some of the burden of having developers manage encryption libraries. Additionally, a CMK cannot be exported from KMS, which alleviates the concern about someone saving the encryption key in an insecure location. You can also leverage AWS CloudTrail so that you have logs of the key’s use.

For the purpose of this post, I have three different AWS Identity and Access Management (IAM) roles to help ensure the security of the PAN data being encrypted:

KeyAdmin – This is the general key administrator role, which has the ability to create and manage the KMS keys. A key administrator does not have the ability to directly use the keys for encrypt and decrypt functions. Keep in mind that because the administrator does have the ability to change a key’s policy, they could escalate their own privilege by changing this policy to give themselves encrypt/decrypt permissions.

PANEncrypt – This role allows the user only to encrypt an object using the CMK.

PANDecrypt – This role allows the user only to decrypt an object using the CMK.

If you don’t already have a CMK that you wish to use to encrypt the sensitive PAN data, you can create one with the following command. (Throughout this post, remember to replace the placeholder text in red with your account-specific information.)

$ aws kms create-key –profile KeyAdmin –description "Key used to encrypt and decrypt sensitive PAN data" –policy file://Key_Policy

Notice the use of –profile KeyAdmin in the previous command. This forces the command to be run as a role specified within my configuration file that has permissions to create a KMS key. We will be using different roles, as defined in the following key policy (to which file://Key_Policy in the previous command refers), to manipulate and use the KMS key. For additional details about how to assume roles within the CLI, see Assuming a Role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessForKeyAdministrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/KeyAdmin"   
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowEncryptionWithTheKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/PANEncrypt"
      },
      "Action": [
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey",
        “kms:ListKeys” 
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowDecryptionWithTheKey",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/PANDecrypt"
      },                             
      "Action": [
        "kms:Decrypt",
      ],
      "Resource": "*"
    }
  ]
}

After the new CMK is created, I can then assign it an alias so that it will be easier to identify in the future. In this case, I will create the alias SensitivePANKey, as shown in the following command.

$ aws kms create-alias –profile KeyAdmin –alias-name alias/SensitivePANKey –target-key-id arn:aws:kms:us-east-1:123456789012:key/221c9ce1-9da8-44e9-801b-faf1EXAMPLE

Now that I have a CMK with least-privilege permissions to limit who can manage and use it, I can start to use it to encrypt PAN data. To keep things simple in this post, I will be using AWS CLI commands to accomplish this, but this can also be done through an AWS SDK and incorporated into an application.

Using the PANEncrypt role, the following CLI command takes in a string of data (in this case “Sensitive PAN Data”), encrypts it using the key I created earlier in this post, and sends the Base64-encoded ciphertext into a new file called encrypted-123-1449012738. Notice that I also use EncryptionContext to further protect the encrypted data. The sensitive PAN data is sent to KMS over TLS (with ciphers that enforce perfect forward secret) and is then encrypted under AES-GCM using a 256-bit key.

$ aws kms encrypt –profile PANEncrypt –key-id alias/SensitivePANKey –plaintext "Sensitive PAN Data" –query CiphertextBlob –encryption-context [email protected],Date=1449012738 –output text | base64 –decode > encrypted-123-1449012738

Because the EncryptionContext must be the same when I decrypt the file, I gave the file a unique name that can help us rebuild the EncryptionContext when it comes time to decrypt the object. The file name structure is: encrypted-GUID-Date. The GUID allows us to look up the user’s user name within our directory, and then I use the date as part of the context. As Greg Rubin discussed in another AWS Security Blog post, the EncryptionContext can help ensure the integrity of the encrypted data.

From here, I can use the following command to put this encrypted object in an Amazon S3 bucket.

$ aws s3 cp encrypted-123-1449012738 s3://Secure-S3-Bucket-For-PAN/ –region us-west-2 –sse aws:kms

For this example, I chose to use native SSE-S3 encryption, but this could have been another KMS key as well. From here, I update a database with the location of this encrypted object within the S3 bucket.

When I need to retrieve the PAN data, I can make the following CLI call to get the encrypted object from my S3 bucket.

$ aws s3 cp s3://Secure-S3-Bucket-For-PAN/ encrypted-123-1449012738 . –region us-west-2

Finally to decrypt the object, I run the following command using the PANDecrypt role.

$ echo “Decrypted PAN Data: $(aws kms decrypt –profile PANDecrypt –CiphertextBlob fileb://encrypted-123-1449012738 –encryption-context [email protected],Date=1449012738 –output text –query Plaintext | base64 –decode)”

Notice that I use the same EncryptionContext as I did when I encrypted the sensitive PAN data. To get this EncryptionContext, I again look up the UserName from the GUID and then include the Date. Then for the purpose of this example, I print this sensitive data to the screen, but in a real-world example, this can be passed to another application or service.

Now that I have shown that KMS can directly encrypt and decrypt sensitive PAN data, this can be rolled out as a service within an application environment. As a best practice, you should avoid using the same KMS CMK to encrypt more than 2 billion objects. After that point, the security of the resulting ciphertexts may be weakened. To mitigate this risk, you can choose to have KMS rotate your CMK annually or you can create multiple CMKs to handle your workloads safely. Additionally, this service should be composed of two different component services: one that provides encryption, and another that has enhanced controls around it and is used to decrypt the sensitive data. These component services would address storage of the ciphertext, metadata, error conditions, and so on. With the integration of CloudTrail into KMS and application logs, an organization can have detailed records of the calls into the service and the use of KMS keys across the organization.

If you have questions or comments about this post, either post them below or visit the KMS forum.

– Matt

AWS ISO 27001 Certification Increases Total In-Scope Services to 33

Post Syndicated from Chad Woolf original https://blogs.aws.amazon.com/security/post/Tx3M70FHVIHHA5O/AWS-ISO-27001-Certification-Increases-Total-In-Scope-Services-to-33

AWS has just completed our annual audit of ISO 27001, a certification we achieved back in 2010. 10 new services are now in scope under ISO 27001:  

Amazon CloudFront

Amazon EC2 Container Service (ECS)

Amazon Elastic File System (EFS)

Amazon Simple Email Service (SES)

Amazon WorkDocs

Amazon WorkMail

Amazon WorkSpaces

AWS Directory Service

AWS Key Management Service (KMS)

AWS WAF – Web Application Firewall

For those just learning about the ISO 27001:2013 certification, the International Organization of Standardization (ISO) created the widely adopted global security standard that set out requirements and best practices for a systematic approach to managing company and customer information. This approach is based on periodic risk assessments appropriate to ever-changing threat scenarios.

Guidance on the 27001 certification from ISO includes:

“Using this family of standards will help your organization manage the security of assets such as financial information, intellectual property, employee details or information entrusted to you by third parties. ISO/IEC 27001 is the best-known standard in the family providing requirements for an information security management system (ISMS).”

This brings the total up to 33 services now available for use under the standard of ISO 27001. The complete list can be found in our AWS ISO 27001 FAQs.

Additionally, 10 regions are now in scope, including the newly added EU (Frankfurt). The complete list is as follows: US East (N. Virginia), US West (Oregon), US West (N. California), AWS GovCloud (US), South America (Sao Paulo), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo).

Download the AWS ISO 27001 certification.

In order to achieve the certification, AWS has shown it has a systematic and ongoing approach to managing information security risks that affect the confidentiality, integrity, and availability of company and customer information. This certification reinforces Amazon’s commitment to providing transparency into our security controls and practices.

AWS was certified by an independent third-party audit, EY CertifyPoint, an ISO certifying agent. Importantly, there is no increase in service costs for any region as a result of this certification. You can download a copy of the AWS certification and use it to jump-start your own certification efforts (you are not automatically certified by association; however, using an ISO 27001 certified provider like AWS can make your certification process easier). You may also want to read the AWS ISO 27001 FAQs.

If you’d like to learn more about compliance in the cloud, please visit our AWS Cloud Compliance page.

– Chad

Subjective explainer: gun debate in the US

Post Syndicated from Michal Zalewski original http://lcamtuf.blogspot.com/2015/10/subjective-explainer-gun-debate-in-us.html

In the wake of the tragic events in Roseburg, I decided to briefly return to the topic of looking at the US culture from the perspective of a person born in Europe. In particular, I wanted to circle back to the topic of firearms.

Contrary to popular beliefs, the United States has witnessed a dramatic decline in violence over the past 20 years. In fact, when it comes to most types of violent crime – say, robbery, assault, or rape – the country now compares favorably to the UK and many other OECD nations. But as I explored in my earlier posts, one particular statistic – homicide – is still registering about three times as high as in many other places within the EU.

The homicide epidemic in the United States has a complex nature and overwhelmingly affects ethnic minorities and other disadvantaged social groups; perhaps because of this, the phenomenon sees very little honest, public scrutiny. It is propelled into the limelight only in the wake of spree shootings and other sickening, seemingly random acts of terror; such incidents, although statistically insignificant, take a profound mental toll on the American society. At the same time, the effects of high-profile violence seem strangely short-lived: they trigger a series of impassioned political speeches, invariably focusing on the connection between violence and guns – but the nation soon goes back to business as usual, knowing full well that another massacre will happen soon, perhaps the very same year.

On the face of it, this pattern defies all reason – angering my friends in Europe and upsetting many brilliant and well-educated progressives in the US. They utter frustrated remarks about the all-powerful gun lobby and the spineless politicians, blaming the partisan gridlock for the failure to pass even the most reasonable and toothless gun control laws. I used to be in the same camp; today, I think the reality is more complex than that.

To get to the bottom of this mystery, it helps to look at the spirit of radical individualism and classical liberalism that remains the national ethos of the United States – and in fact, is enjoying a degree of resurgence unseen for many decades prior. In Europe, it has long been settled that many individual liberties – be it the freedom of speech or the natural right to self-defense – can be constrained to advance even some fairly far-fetched communal goals. On the old continent, such sacrifices sometimes paid off, and sometimes led to atrocities; but the basic premise of European collectivism is not up for serious debate. In America, the same notion certainly cannot be taken for granted today.

When it comes to firearm ownership in particular, the country is facing a fundamental choice between two possible realities:

A largely disarmed society that depends on the state to protect it from almost all harm, and where citizens are generally not permitted to own guns without presenting a compelling cause. In this model, adopted by many European countries, firearms tend to be less available to common criminals – simply by the virtue of limited supply and comparatively high prices in black market trade. At the same time, it can be argued that any nation subscribing to this doctrine becomes more vulnerable to foreign invasion or domestic terror, should its government ever fail to provide adequate protection to all citizens. Disarmament can also limit civilian recourse against illegitimate, totalitarian governments – a seemingly outlandish concern, but also a very fresh memory for many European countries subjugated not long ago under the auspices of the Soviet Bloc.

A well-armed society where firearms are available to almost all competent adults, and where the natural right to self-defense is subject to few constraints. This is the model currently employed in the United States, where it arises from the straightfoward, originalist interpretation of the Second Amendment – as recognized by roughly 75% of all Americans and affirmed by the Supreme Court. When following such a doctrine, a country will likely witness greater resiliency in the face of calamities or totalitarian regimes. At the same time, its citizens might have to accept some inherent, non-trivial increase in violent crime due to the prospect of firearms more easily falling into the wrong hands.

It seems doubtful that a viable middle-ground approach can exist in the United States. With more than 300 million civilian firearms in circulation, most of them in unknown hands, the premise of reducing crime through gun control would inevitably and critically depend on some form of confiscation; without such drastic steps, the supply of firearms to the criminal underground or to unfit individuals would not be disrupted in any meaningful way. Because of this, intellectual integrity requires us to look at many of the legislative proposals not only through the prism of their immediate utility, but also to give consideration to the societal model they are likely to advance.

And herein lies the problem: many of the current “common-sense” gun control proposals have very little merit when considered in isolation. There is scant evidence that reinstating the ban on military-looking semi-automatic rifles (“assault weapons”), or rolling out the prohibition on private sales at gun shows, would deliver measurable results. There is also no compelling reason to believe that ammo taxes, firearm owner liability insurance, mandatory gun store cameras, firearm-free school zones, bans on open carry, or federal gun registration can have any impact on violent crime. And so, the debate often plays out like this:

At the same time, by the virtue of making weapons more difficult, expensive, and burdensome to own, many of the legislative proposals floated by progressives would probably gradually erode the US gun culture; intentionally or not, their long-term outcome would be a society less passionate about firearms and more willing to follow in the footsteps of Australia or the UK. Only as we cross that line and confiscate hundreds of millions of guns, it’s fathomable – yet still far from certain – that we would see a sharp drop in homicides.

This method of inquiry helps explain the visceral response from gun rights advocates: given the legislation’s dubious benefits and its predicted long-term consequences, many pro-gun folks are genuinely worried that making concessions would eventually mean giving up one of their cherished civil liberties – and on some level, they are right.

Some feel that this argument is a fallacy, a tell tale invented by a sinister corporate “gun lobby” to derail the political debate for personal gain. But the evidence of such a conspiracy is hard to find; in fact, it seems that the progressives themselves often fan the flames. In the wake of Roseburg, both Barack Obama and Hillary Clinton came out praising the confiscation-based gun control regimes employed in Australia and the UK – and said that they would like the US to follow suit. Depending on where you stand on the issue, it was either an accidental display of political naivete, or the final reveal of their sinister plan. For the latter camp, the ultimate proof of a progressive agenda came a bit later: in response to the terrorist attack in San Bernardino, several eminent Democratic-leaning newspapers published scathing editorials demanding civilian disarmament while downplaying the attackers’ connection to Islamic State.

Another factor that poisons the debate is that despite being highly educated and eloquent, the progressive proponents of gun control measures are often hopelessly unfamiliar with the very devices they are trying to outlaw:

I’m reminded of the widespread contempt faced by Senator Ted Stevens following his attempt to compare the Internet to a “series of tubes” as he was arguing against net neutrality. His analogy wasn’t very wrong – it just struck a nerve as simplistic and out-of-date. My progressive friends did not react the same way when Representative Carolyn McCarthy – one of the key proponents of the ban on assault weapons – showed no understanding of the supposedly lethal firearm features she was trying to eradicate. Such bloopers are not rare, too; not long ago, Mr. Bloomberg, one of the leading progressive voices on gun control in America, argued against semi-automatic rifles without understanding how they differ from the already-illegal machine guns:

Yet another example comes Representative Diana DeGette, the lead sponsor of a “common-sense” bill that sought to prohibit the manufacture of magazines with capacity over 15 rounds. She defended the merits of her legislation while clearly not understanding how a magazine differs from ammunition – or that the former can be reused:

“I will tell you these are ammunition, they’re bullets, so the people who have those know they’re going to shoot them, so if you ban them in the future, the number of these high capacity magazines is going to decrease dramatically over time because the bullets will have been shot and there won’t be any more available.”

Treating gun ownership with almost comical condescension has become vogue among a good number of progressive liberals. On a campaign stop in San Francisco, Mr. Obama sketched a caricature of bitter, rural voters who “cling to guns or religion or antipathy to people who aren’t like them”. Not much later, one Pulitzer Prize-winning columnist for The Washington Post spoke of the Second Amendment as “the refuge of bumpkins and yeehaws who like to think they are protecting their homes against imagined swarthy marauders desperate to steal their flea-bitten sofas from their rotting front porches”. Many of the newspaper’s readers probably had a good laugh – and then wondered why it has gotten so difficult to seek sensible compromise.

There are countless dubious and polarizing claims made by the supporters of gun rights, too; examples include a recent NRA-backed tirade by Dana Loesch denouncing the “godless left”, or the constant onslaught of conspiracy theories spewed by Alex Jones and Glenn Beck. But when introducing new legislation, the burden of making educated and thoughtful arguments should rest on its proponents, not other citizens. When folks such as Bloomberg prescribe sweeping changes to the American society while demonstrating striking ignorance about the topics they want to regulate, they come across as elitist and flippant – and deservedly so.

Given how controversial the topic is, I think it’s wise to start an open, national conversation about the European model of gun control and the risks and benefits of living in an unarmed society. But it’s also likely that such a debate wouldn’t last very long. Progressive politicians like to say that the dialogue is impossible because of the undue influence of the National Rifle Association – but as I discussed in my earlier blog posts, the organization’s financial resources and power are often overstated: it does not even make it onto the list of top 100 lobbyists in Washington, and its support comes mostly from member dues, not from shadowy business interests or wealthy oligarchs. In reality, disarmament just happens to be a very unpopular policy in America today: the support for gun ownership is very strong and has been growing over the past 20 years – even though hunting is on the decline.

Perhaps it would serve the progressive movement better to embrace the gun culture – and then think of ways to curb its unwanted costs. Addressing inner-city violence, especially among the disadvantaged youth, would quickly bring the US homicide rate much closer to the rest of the highly developed world. But admitting the staggering scale of this social problem can be an uncomfortable and politically charged position to hold. For Democrats, it would be tantamount to singling out minorities. For Republicans, it would be just another expansion of the nanny state.

PS. If you are interested in a more systematic evaluation of the scale, the impact, and the politics of gun ownership in the United States, you may enjoy an earlier entry on this blog. Or, if you prefer to read my entire series comparing the life in Europe and in the US, try this link.

Subjective explainer: gun debate in the US

Post Syndicated from Michal Zalewski original http://lcamtuf.blogspot.com/2015/10/subjective-explainer-gun-debate-in-us.html

In the wake of the tragic events in Roseburg, I decided to briefly return to the topic of looking at the US culture from the perspective of a person born in Europe. In particular, I wanted to circle back to the topic of firearms.

Contrary to popular beliefs, the United States has witnessed a dramatic decline in violence over the past 20 years. In fact, when it comes to most types of violent crime – say, robbery, assault, or rape – the country now compares favorably to the UK and many other OECD nations. But as I explored in my earlier posts, one particular statistic – homicide – is still registering about three times as high as in many other places within the EU.

The homicide epidemic in the United States has a complex nature and overwhelmingly affects ethnic minorities and other disadvantaged social groups; perhaps because of this, the phenomenon sees very little honest, public scrutiny. It is propelled into the limelight only in the wake of spree shootings and other sickening, seemingly random acts of terror; such incidents, although statistically insignificant, take a profound mental toll on the American society. At the same time, the effects of high-profile violence seem strangely short-lived: they trigger a series of impassioned political speeches, invariably focusing on the connection between violence and guns – but the nation soon goes back to business as usual, knowing full well that another massacre will happen soon, perhaps the very same year.

On the face of it, this pattern defies all reason – angering my friends in Europe and upsetting many brilliant and well-educated progressives in the US. They utter frustrated remarks about the all-powerful gun lobby and the spineless politicians, blaming the partisan gridlock for the failure to pass even the most reasonable and toothless gun control laws. I used to be in the same camp; today, I think the reality is more complex than that.

To get to the bottom of this mystery, it helps to look at the spirit of radical individualism and classical liberalism that remains the national ethos of the United States – and in fact, is enjoying a degree of resurgence unseen for many decades prior. In Europe, it has long been settled that many individual liberties – be it the freedom of speech or the natural right to self-defense – can be constrained to advance even some fairly far-fetched communal goals. On the old continent, such sacrifices sometimes paid off, and sometimes led to atrocities; but the basic premise of European collectivism is not up for serious debate. In America, the same notion certainly cannot be taken for granted today.

When it comes to firearm ownership in particular, the country is facing a fundamental choice between two possible realities:

A largely disarmed society that depends on the state to protect it from almost all harm, and where citizens are generally not permitted to own guns without presenting a compelling cause. In this model, adopted by many European countries, firearms tend to be less available to common criminals – simply by the virtue of limited supply and comparatively high prices in black market trade. At the same time, it can be argued that any nation subscribing to this doctrine becomes more vulnerable to foreign invasion or domestic terror, should its government ever fail to provide adequate protection to all citizens. Disarmament can also limit civilian recourse against illegitimate, totalitarian governments – a seemingly outlandish concern, but also a very fresh memory for many European countries subjugated not long ago under the auspices of the Soviet Bloc.

A well-armed society where firearms are available to almost all competent adults, and where the natural right to self-defense is subject to few constraints. This is the model currently employed in the United States, where it arises from the straightfoward, originalist interpretation of the Second Amendment – as recognized by roughly 75% of all Americans and affirmed by the Supreme Court. When following such a doctrine, a country will likely witness greater resiliency in the face of calamities or totalitarian regimes. At the same time, its citizens might have to accept some inherent, non-trivial increase in violent crime due to the prospect of firearms more easily falling into the wrong hands.

It seems doubtful that a viable middle-ground approach can exist in the United States. With more than 300 million civilian firearms in circulation, most of them in unknown hands, the premise of reducing crime through gun control would inevitably and critically depend on some form of confiscation; without such drastic steps, the supply of firearms to the criminal underground or to unfit individuals would not be disrupted in any meaningful way. Because of this, intellectual integrity requires us to look at many of the legislative proposals not only through the prism of their immediate utility, but also to give consideration to the societal model they are likely to advance.

And herein lies the problem: many of the current “common-sense” gun control proposals have very little merit when considered in isolation. There is scant evidence that reinstating the ban on military-looking semi-automatic rifles (“assault weapons”), or rolling out the prohibition on private sales at gun shows, would deliver measurable results. There is also no compelling reason to believe that ammo taxes, firearm owner liability insurance, mandatory gun store cameras, firearm-free school zones, bans on open carry, or federal gun registration can have any impact on violent crime. And so, the debate often plays out like this:

At the same time, by the virtue of making weapons more difficult, expensive, and burdensome to own, many of the legislative proposals floated by progressives would probably gradually erode the US gun culture; intentionally or not, their long-term outcome would be a society less passionate about firearms and more willing to follow in the footsteps of Australia or the UK. Only as we cross that line and confiscate hundreds of millions of guns, it’s fathomable – yet still far from certain – that we would see a sharp drop in homicides.

This method of inquiry helps explain the visceral response from gun rights advocates: given the legislation’s dubious benefits and its predicted long-term consequences, many pro-gun folks are genuinely worried that making concessions would eventually mean giving up one of their cherished civil liberties – and on some level, they are right.

Some feel that this argument is a fallacy, a tell tale invented by a sinister corporate “gun lobby” to derail the political debate for personal gain. But the evidence of such a conspiracy is hard to find; in fact, it seems that the progressives themselves often fan the flames. In the wake of Roseburg, both Barack Obama and Hillary Clinton came out praising the confiscation-based gun control regimes employed in Australia and the UK – and said that they would like the US to follow suit. Depending on where you stand on the issue, it was either an accidental display of political naivete, or the final reveal of their sinister plan. For the latter camp, the ultimate proof of a progressive agenda came a bit later: in response to the terrorist attack in San Bernardino, several eminent Democratic-leaning newspapers published scathing editorials demanding civilian disarmament while downplaying the attackers’ connection to Islamic State.

Another factor that poisons the debate is that despite being highly educated and eloquent, the progressive proponents of gun control measures are often hopelessly unfamiliar with the very devices they are trying to outlaw:

I’m reminded of the widespread contempt faced by Senator Ted Stevens following his attempt to compare the Internet to a “series of tubes” as he was arguing against net neutrality. His analogy wasn’t very wrong – it just struck a nerve as simplistic and out-of-date. My progressive friends did not react the same way when Representative Carolyn McCarthy – one of the key proponents of the ban on assault weapons – showed no understanding of the supposedly lethal firearm features she was trying to eradicate. Such bloopers are not rare, too; not long ago, Mr. Bloomberg, one of the leading progressive voices on gun control in America, argued against semi-automatic rifles without understanding how they differ from the already-illegal machine guns:

Yet another example comes Representative Diana DeGette, the lead sponsor of a “common-sense” bill that sought to prohibit the manufacture of magazines with capacity over 15 rounds. She defended the merits of her legislation while clearly not understanding how a magazine differs from ammunition – or that the former can be reused:

“I will tell you these are ammunition, they’re bullets, so the people who have those know they’re going to shoot them, so if you ban them in the future, the number of these high capacity magazines is going to decrease dramatically over time because the bullets will have been shot and there won’t be any more available.”

Treating gun ownership with almost comical condescension has become vogue among a good number of progressive liberals. On a campaign stop in San Francisco, Mr. Obama sketched a caricature of bitter, rural voters who “cling to guns or religion or antipathy to people who aren’t like them”. Not much later, one Pulitzer Prize-winning columnist for The Washington Post spoke of the Second Amendment as “the refuge of bumpkins and yeehaws who like to think they are protecting their homes against imagined swarthy marauders desperate to steal their flea-bitten sofas from their rotting front porches”. Many of the newspaper’s readers probably had a good laugh – and then wondered why it has gotten so difficult to seek sensible compromise.

There are countless dubious and polarizing claims made by the supporters of gun rights, too; examples include a recent NRA-backed tirade by Dana Loesch denouncing the “godless left”, or the constant onslaught of conspiracy theories spewed by Alex Jones and Glenn Beck. But when introducing new legislation, the burden of making educated and thoughtful arguments should rest on its proponents, not other citizens. When folks such as Bloomberg prescribe sweeping changes to the American society while demonstrating striking ignorance about the topics they want to regulate, they come across as elitist and flippant – and deservedly so.

Given how controversial the topic is, I think it’s wise to start an open, national conversation about the European model of gun control and the risks and benefits of living in an unarmed society. But it’s also likely that such a debate wouldn’t last very long. Progressive politicians like to say that the dialogue is impossible because of the undue influence of the National Rifle Association – but as I discussed in my earlier blog posts, the organization’s financial resources and power are often overstated: it does not even make it onto the list of top 100 lobbyists in Washington, and its support comes mostly from member dues, not from shadowy business interests or wealthy oligarchs. In reality, disarmament just happens to be a very unpopular policy in America today: the support for gun ownership is very strong and has been growing over the past 20 years – even though hunting is on the decline.

Perhaps it would serve the progressive movement better to embrace the gun culture – and then think of ways to curb its unwanted costs. Addressing inner-city violence, especially among the disadvantaged youth, would quickly bring the US homicide rate much closer to the rest of the highly developed world. But admitting the staggering scale of this social problem can be an uncomfortable and politically charged position to hold. For Democrats, it would be tantamount to singling out minorities. For Republicans, it would be just another expansion of the nanny state.

PS. If you are interested in a more systematic evaluation of the scale, the impact, and the politics of gun ownership in the United States, you may enjoy an earlier entry on this blog. Or, if you prefer to read my entire series comparing the life in Europe and in the US, try this link.

SSDs: A gift and a curse

Post Syndicated from Laurie Denness original https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/

Artur Bergman, founder of a CDN exclusively powered by super fast SSDs, has made many compelling cases over the years to use them. He was definitely ahead of the curve here, but he’s right. Nowadays, they’re denser, 100x faster and as competitively priced as hard disks in most server configurations.

At Etsy, we’ve been trying to get on this bandwagon for the last 5 years too. It’s got a lot better value for money in the last year, so we’ve gone from “dipping our toes in the water” to “ORDER EVERYTHING WITH SSDs!” pretty rapidly.

This isn’t a post about how great SSDs are though: Seriously, they’re amazing. The new Dell R630 allows for 24x 960GB 1.8″ SSDs in a 1U chassis. That’s 19TB usable ludicrously fast, sub millisecond latency storage after RAID6, that will blow away anything you can get on spinning rust, use less power, and is actually reasonably priced per GB.

Picture of Dell R630, 24x 960GB SSDs in 1U chassis
Plus, they look amazing.

So if this post isn’t “GO BUY ALL THE SSDs NOW”, what is it? Well, it’s a cautionary tale that it’s not all unicorns and IOPs.

The problem(s) with SSDs

When SSDs first started to come out, people were concerned that these drives “only” handled a certain number of operations or data during their lifetime, and they’d be changing SSDs far more frequently than conventional spinning rust. Actually, that’s totally not the case and we haven’t experienced that at all. We have thousands of SSDs, and we’ve lost maybe one or two to old age, and it probably wasn’t wear related.

Spoiler alert: SSD firmware is buggy

When was the last time your hard disk failed because the firmware did something whacky? Well, Seagate had a pretty famous case back in 2009 where the drives may not ever power on again if you power them off. Whoops.

But the majority of times, the issue is the physical hardware… The infamous “spinning rust” that is in the drive.

So, SSDs solve this forever right? No moving parts.. Measured mean time to failure of hundreds of years before the memory wears out? Perfect!

Here’s the run down of the firmware issues we’ve had over 5 or so years:

Intel

Okay, bad start, we’ve actually had no issues with Intel. This seems to be common across other companies we’ve spoken to. We started putting single 160GB in our web servers about 4 years ago, because it gave us low power, fast, reliable storage and the space requirements for web servers and utility boxes was low anyway. No more waiting for the metal to seize up! We have SSDs that have long outlived the servers.

OCZ

Outside of the 160GB Intel drives, our search (Solr) stack was the first to benefit from denser, fast storage. Search indexes were getting big; too big for memory. In addition, getting them off disk and serving search results to users was limited by the random disk latency.

Rather than many expensive, relatively fast but low capacity spinning rust drives in a RAID array, we opted for OCZ Talos 960GB disks. These weren’t too bad; we had a spate of initial failures in what seemed like a bad batch, but we were able to learn from this and make the app more resilient to failures.

However, they had poor SMART info (none) so predicting failures was hard.

Unfortunately, the company later went bankrupt, and Toshiba rescued them from the dead. They were unavailable for long enough that we simply ditched them and moved on.

HP SSDs

We briefly tried running third party SSDs on our older (HP) Graphite boxes… This was a quick, fairly cheap win as it got us a tonne of performance for relatively little money (back then we needed much less Graphite storage). This worked fine until the drives started to fail.

Unfortunately, HP have proprietary RAID controllers, and they don’t support SMART. Or rather, they refuse to talk to non-HP drives using off the shelf technology, they have their own methods.

Slot an unsupported disk or SSD into the controller, and you have no idea how that drive is performing or failing. We quickly learnt this after running for a while on these boxes, and performance randomly tanked. The SSDs underlying the RAID array seemed to be dying and slowing down, and we had no way of knowing which one (or ones), or how to fix it. Presumably the drives were not being issued TRIM commands either.

When we had to purchase a new box for our primary database this left us with no choice: We have to pay HP for SSDs. 960GB SSDs direct from HP, properly supported, cost us around $7000 each. Yes, each. We had to buy 4 of them to get the storage we needed.

On the upside, they do have fancy detailed stats (like wear levelling) exposed via the controller and ILO, and none have failed yet almost 3 years on (in fact, they’re all showing 99% health). You get what you pay for, luckily.

Samsung

Samsung saved the day and picked up from OCZ with a ludicrously cheap 960GB offering, the 840 EVO. A consumer drive, so very limited warranty, but for the price (~$400-500) you got great IOPS and they were reliable. They had better SMART info, and seemed to play nicely with our hardware.

We have a lot of these drives:

[~/chef-repo (master)] $ knife search node block_device_sda_model:'Samsung' -a block_device.sda.model

117 items found

That’s 117 hosts with those drives, most of them have 6 each, and doesn’t include hosts that have them behind RAID controllers (for example, our Graphite boxes). In particular, they’ve been awesome for our ELK logging cluster

Then BB6Q happened…

I hinted that we used these for Graphite. They worked great! Who wouldn’t want thousands and thousands of IOPs for relatively little money? Buying SSDs from OEMs is still expensive, and they give you those darn fancy “enterprise” level drives. Pfft. Redundancy at the app level, right?

We had started buying Dell, who use a rebranded LSI RAID controller so they happily talked to the drives including providing full SMART info. We had 16 of those Samsung drives behind the Dell controller giving us 7.3TB of super fast storage.

Given the already proven pattern, we ordered the same spec box for a Ganglia hardware refresh. And they didn’t work. The RAID controller hung on startup trying to initialise the drives, so long that the Boot ROM was never loaded so it was impossible to boot from an array created using them.

What had changed?! A quick

"MegaCli -AdpAllInfo -a0 | diff"

on the two boxes, revealed: The firmware on the drive had changed. (shout out to those of you who know the MegaCli parameters by heart now…)

Weeks of debugging and back and forth with both Dell (who were very nice given these drives were unsupported) and Samsung revealed there were definitely firmware issues with this particular BB6Q release.

It was soon released publicly, that not only did this new firmware somehow break compatibility with Dell RAID controllers (by accident), but they also had a crippling performance bug… They got slower and slower over time, because they had messed up their block allocation algorithm.

In the end, behind LSI controllers, it was the controller sending particular ATA commands to the drives that would make them hang and not respond.. And so the RAID controller would have to wait for it to time out.

Samsung put out a firmware updater and “fixer” tool for this, but it needed to move your data around so only ran on Windows with NTFS.

With hundreds of these things that are in production and working, but have a crippling performance issue, we had to figure out how they would get flashed. An awesome contractor for Samsung agreed that if we drove over batches of drives (luckily, they are incredibly close to our datacenter) they would flash them and return them the next day.

This story has a relatively happy ending then; our drives are getting fixed, and we’re still buying their drives; now the 960GB 850 PRO model, as they remain a great value for money high performance drive.

Talking with other companies, we’re not alone with Samsung issues like this, even the 840 PRO has some issues that require hard power cycles to fix. But the price is hard to beat, especially now the 850 range is looking more solid.

LiteOn

LiteOn were famously known for making CD writers back when CD writers were new and exciting.

But they’re also a chosen OEM partner of Dell’s for their official “value” SSDs. Value is a relative term here, but they’re infinitely cheaper than HP’s offerings, enterprise level, fully supported and for all that, “only” twice the price of Samsung (~$940)

We decided to buy new SSD based database boxes, because SSDs were too hard to resist for these use cases; crazy performance and at 1TB capacity, not too much more expensive per GB than spinning rust. We had to buy many many 15,000rpm drives to even get near the performance, and they were expensive at 300GB capacity. We could spend a bit more money and save power, rack space, and get more disk space and IOPs.

For similar reasons to HP, we thought best to pay the premium for a fully supported solution, especially as Samsung had just caused all these issue with their firmware issues.

With that in mind, we ordered some R630’s hot off the production line with 960GB LiteOn’s, tested performance, and it was great: 30,000 random write IOPs across 4 SSDs in RAID6, (5.5 TB useable space).

We put them live, and they promptly blew up spectacularly. (Yes, we had a postmortem about this). The RAID controller claimed that two drives had died simultaneously, with another being reset by the adapter. Did we really get two disks to die at once?

This took months of working closely with Dell to figure out. Replacement of drives, backplane, and then the whole box, but the problem persisted. Just a few short hours of intense IO, especially on a box with only 4 SSDs would cause them to flip out. And in the mean time, we’d ordered 50+ of these boxes with varying amounts of SSDs installed, having tested so well initially.

Eventually it transpires that, like most good problems, it was a combination of many factors that caused these issues. The SSDs were having extended garbage collection periods, exacerbated by a smaller amount of SSDs with higher IO, in RAID6. This caused the controller to kick the drive out of the array… and unfortunately due to the write levelling across the drives, at least two of them were garbage collecting at the same time, destroying the array integrity.

The fix was no small deal; Dell and LiteOn together identified and fixed weaknesses in their RAID controller, the backplane and the SSD firmware. It was great to see the companies working together rather than just pointing fingers here, and the fixes for all sizes except 960GB was out within a month.

The story here continues for us though; the 960GB drive remains unsolved, as it caused more issues, and we had almost exclusively purchased those. For systems that weren’t fully loaded, Dell kindly provided us with 800GB replacements and extra drives to make up the space. For the rest, because the stress across the 22 drives means garbage collection isn’t as intense, so they remain operating until a firmware fix.

Summary

I’m hesitant to recommend any one particular brand, because I’m sure as with the hard disk phenomenon (Law where each person has their preferred brand that they’ve never had issues with but everyone else has), people’s experiences will have varied.

We should probably collect some real data on this as an industry and share it around; I’ve always been of the mindset that we’re weirdly secretive sometimes of what hardware/software we use but we should share, so if anyone wants to contribute let me know.

But: you can probably continue to buy Intel and Samsung, depending on your use case/budget, and as usual, own your own availability and add resiliency to your apps and hardware, because things always fail in ways you can’t imagine.

SPF and Amazon SES

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx3IREZBQXXL8O8/SPF-and-Amazon-SES

Update (3/14/16): To increase your SPF authentication options, Amazon SES now enables you to use your own MAIL FROM domain. For more information, see Authenticating Email with SPF in Amazon SES.

One of the most important aspects of email communication today is making sure the right person sent you the right message. There are several standards in place to address various aspects of securing email sending; one of the most commonly known is SPF (the short form of Sender Policy Framework). In this blog post we explain what SPF is, how it works, and how Amazon SES handles it. We also address the most common questions we see from customers with regard to their concerns around email security.

What is SPF?

Described in RFC 7208 (http://tools.ietf.org/html/rfc7208 ), SPF is an open standard designed to prevent sender address forgery. In particular, it is used to confirm that the IP address from which an email originates is allowed to send emails by the owner of the domain that sent the email. What does that mean and how does it happen?

Before going into how SPF works, we should clarify exactly what it does and does not do. First, let’s separate the actual email message body and its headers from the SMTP protocol used to send it. SPF works by authenticating the IP address that originated the SMTP connection to the domain used in the SMTP MAIL-FROM and/or the HELO/EHLO command. The From header, which is part of the email message itself, is not covered by SPF validation. A separate standard, DomainKeys Identified Mail (DKIM), is used to authenticate the message body and headers against the From header domain (which can be different from the domain used in the SMTP MAIL-FROM command).

Now that we’ve talked about what SPF does, let’s look at how it actually works. SPF involves publishing a DNS record in the domain that wants to allow IP addresses to send from it. This DNS record needs to contain either blocks of IP addresses that are permitted to send from it, or another domain to which authorization is delegated (or both). When an ISP receives an email and wants to validate that the IP address that sent the mail is allowed to send it on behalf of the sending domain, the ISP performs a DNS query against the SPF record. If such a record exists and contains the IP address in question or delegates to a domain that contains it, then we know that the IP address is authorized to send emails from that domain.

SPF and Amazon SES

If you are using Amazon SES to send from your domain, you need to know that the current SES implementation involves sending emails from an SES-owned MAIL-FROM domain. This means that you do not need to make any changes to your DNS records in order for your emails to pass SPF authentication.

Common concerns

There are a couple of questions we frequently hear from customers with regard to SPF authorization and how it relates to Amazon SES usage.

The first concern seems to be how your sending is affected if SPF authentication is performed against Amazon SES and not against your own domain.

If you’re wondering whether any other SES customer can send on your behalf, the answer is no. SES does not allow sending from a specific domain or email address until that domain or email address has been successfully verified with SES, a process that cannot take place without the consent of the domain/address’s owner.

The next question is whether you can still have a mechanism under your control that can authenticate the email-related content that you do control (things such as the message body, or various headers such as the From header, subject, or destinations). The answer is yes — Amazon SES offers DKIM signing capabilities (or the possibility to roll out your own). DKIM is another open standard that can authenticate the integrity of an email message, including its content and headers, and can prove to ISPs that your domain (not Amazon’s or someone else’s) takes responsibility and claims ownership of that specific email.

Another concern you may have is how much flexibility you get in using SPF to elicit a specific ISP response for unauthenticated or unauthorized emails from your domain. In particular, this concern translates into configuring DMARC (short for Domain-based Message Authentication, Reporting & Conformance) to work with SES. DMARC is a standard way of telling ISPs how to handle unauthenticated emails, and it’s based on both a) Successful SPF and/or DKIM authentication and b) Domain alignment (all authenticated domains must match). As explained above, your MAIL-FROM domain is currently an SES domain, which doesn’t match your sending domain (From header). As a result, SPF authentication will be misaligned for DMARC purposes. DKIM, on the other hand, provides the necessary domain alignment and ultimately satisfies DMARC because you are authenticating your From domain.

Simply put, you must enable DKIM signing for your verified domain in order to be able to successfully configure DMARC for your domain.

 If you have any questions, comments or other concerns related to SPF and your Amazon SES sending, don’t hesitate to jump on the Amazon SES Forum and let us know. Thank you for choosing SES and happy sending!

SPF and Amazon SES

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx3IREZBQXXL8O8/SPF-and-Amazon-SES

Update (3/14/16): To increase your SPF authentication options, Amazon SES now enables you to use your own MAIL FROM domain. For more information, see Authenticating Email with SPF in Amazon SES.

One of the most important aspects of email communication today is making sure the right person sent you the right message. There are several standards in place to address various aspects of securing email sending; one of the most commonly known is SPF (the short form of Sender Policy Framework). In this blog post we explain what SPF is, how it works, and how Amazon SES handles it. We also address the most common questions we see from customers with regard to their concerns around email security.

What is SPF?

Described in RFC 7208 (http://tools.ietf.org/html/rfc7208 ), SPF is an open standard designed to prevent sender address forgery. In particular, it is used to confirm that the IP address from which an email originates is allowed to send emails by the owner of the domain that sent the email. What does that mean and how does it happen?

Before going into how SPF works, we should clarify exactly what it does and does not do. First, let’s separate the actual email message body and its headers from the SMTP protocol used to send it. SPF works by authenticating the IP address that originated the SMTP connection to the domain used in the SMTP MAIL-FROM and/or the HELO/EHLO command. The From header, which is part of the email message itself, is not covered by SPF validation. A separate standard, DomainKeys Identified Mail (DKIM), is used to authenticate the message body and headers against the From header domain (which can be different from the domain used in the SMTP MAIL-FROM command).

Now that we’ve talked about what SPF does, let’s look at how it actually works. SPF involves publishing a DNS record in the domain that wants to allow IP addresses to send from it. This DNS record needs to contain either blocks of IP addresses that are permitted to send from it, or another domain to which authorization is delegated (or both). When an ISP receives an email and wants to validate that the IP address that sent the mail is allowed to send it on behalf of the sending domain, the ISP performs a DNS query against the SPF record. If such a record exists and contains the IP address in question or delegates to a domain that contains it, then we know that the IP address is authorized to send emails from that domain.

SPF and Amazon SES

If you are using Amazon SES to send from your domain, you need to know that the current SES implementation involves sending emails from an SES-owned MAIL-FROM domain. This means that you do not need to make any changes to your DNS records in order for your emails to pass SPF authentication.

Common concerns

There are a couple of questions we frequently hear from customers with regard to SPF authorization and how it relates to Amazon SES usage.

The first concern seems to be how your sending is affected if SPF authentication is performed against Amazon SES and not against your own domain.

If you’re wondering whether any other SES customer can send on your behalf, the answer is no. SES does not allow sending from a specific domain or email address until that domain or email address has been successfully verified with SES, a process that cannot take place without the consent of the domain/address’s owner.

The next question is whether you can still have a mechanism under your control that can authenticate the email-related content that you do control (things such as the message body, or various headers such as the From header, subject, or destinations). The answer is yes — Amazon SES offers DKIM signing capabilities (or the possibility to roll out your own). DKIM is another open standard that can authenticate the integrity of an email message, including its content and headers, and can prove to ISPs that your domain (not Amazon’s or someone else’s) takes responsibility and claims ownership of that specific email.

Another concern you may have is how much flexibility you get in using SPF to elicit a specific ISP response for unauthenticated or unauthorized emails from your domain. In particular, this concern translates into configuring DMARC (short for Domain-based Message Authentication, Reporting & Conformance) to work with SES. DMARC is a standard way of telling ISPs how to handle unauthenticated emails, and it’s based on both a) Successful SPF and/or DKIM authentication and b) Domain alignment (all authenticated domains must match). As explained above, your MAIL-FROM domain is currently an SES domain, which doesn’t match your sending domain (From header). As a result, SPF authentication will be misaligned for DMARC purposes. DKIM, on the other hand, provides the necessary domain alignment and ultimately satisfies DMARC because you are authenticating your From domain.

Simply put, you must enable DKIM signing for your verified domain in order to be able to successfully configure DMARC for your domain.

 If you have any questions, comments or other concerns related to SPF and your Amazon SES sending, don’t hesitate to jump on the Amazon SES Forum and let us know. Thank you for choosing SES and happy sending!

DKIM Troubleshooting Series: Authentication Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2NCXUV8X3Z0WS/DKIM-Troubleshooting-Series-Authentication-Considerations

Hi, and welcome to another entry in the Amazon SES DKIM troubleshooting series. So far we have focused on technical issues, but now it’s time to take a step back and look at the bigger picture. Exactly why did we go to all this trouble in setting up DKIM for our domain?
My emails are signed and the signature validates. Does this mean I’m safe from spoofing attacks?
Even if all our email is DKIM signed and validated by all ISPs, this is no time to rest. The world is full of ethically dubious people who want to impersonate us and steal our customers, and DKIM is only step one in protecting ourselves.
So what exactly is DKIM doing to help us with this? The way this standard ensures the integrity of our emails is to calculate a hash of the message’s body and some of its headers, and then to digitally sign the hash. As long as the private key is kept secure, and the public key is accessible through DNS, the DKIM signature gives ISPs confidence that the domain that signs the message acknowledges its content through the signature. Let’s have another look at the DKIM signature to see exactly what we’re talking about:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
The "d" tag represents the domain that signs the email. In this case that would be our own domain, ses-example.com. This domain takes responsibility for the email, guaranteeing its integrity through the signature. The "h" tag contains a list of all of the headers of this email that are signed (and thus have their integrity guaranteed) by the signing domain. The "bh" tag is the result of a hash function applied to the email’s body (very useful to ensure that the content itself hasn’t been tampered with). Finally, the "b" tag is the actual signature itself, applied to the body hash and headers. If that checks out, then both the message body and all of the headers included in the "h" tag are considered to be authenticated by the signing domain.
That’s all very nice, but how does it stop an attacker?
The hashing and key encryption algorithms we use are well known, so surely anyone can generate their own key pair and calculate the signature themselves, right? In fact… this is actually true. Anyone can sign any email with a DKIM signature, the problem is getting ISPs to trust that that signature is ours and not the attacker’s. The key here is in the "s" and "d" tags of the signature. The "d" tag is our domain, and the "s" (or "selector") tag indicates which of our domain’s signing keys has been used for this particular email. It’s these two tags that help build the location of the public key in DNS and form the obstacle in the attacker’s path. In this signature’s case, any ISP that wants to validate our email will try to retrieve the public key from a record xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com ( <selector>._domainkey.<domain> ). An attacker can calculate hashes and signatures all they want but they won’t have permission to publish any key they control into our DNS, so they will never be able to compute a signature that has our domain as the "d" tag (and thus has its integrity guaranteed by us). DNS spoofing, it turns out, is not so easy to perform (although it has happened)! With only the public key visible in DNS, it is not computationally easy for any attacker to deduce the private part. Just in case, SES regularly rotates the keys, to thwart any such attempt.
Setting up DMARC can also signal ISPs to drop all emails that aren’t authenticated (via DKIM or SPF). If an attacker wants to impersonate our domain they can either put in a broken signature or no signature at all. In both cases, DMARC signals ISPs to quarantine (put in the Spam folder) or drop those emails. That is definitely a good step forward in dealing with phishing spam!
SES also offers other forms of authentication such as SPF, which are highly recommended and will further improve our security.
Next Steps
In the next blog entry, we will have a look at another email-related concept that is indirectly influenced by DKIM: deliverability.

DKIM Troubleshooting Series: Authentication Considerations

Post Syndicated from Adrian Hamciuc original http://sesblog.amazon.com/post/Tx2NCXUV8X3Z0WS/DKIM-Troubleshooting-Series-Authentication-Considerations

Hi, and welcome to another entry in the Amazon SES DKIM troubleshooting series. So far we have focused on technical issues, but now it’s time to take a step back and look at the bigger picture. Exactly why did we go to all this trouble in setting up DKIM for our domain?
My emails are signed and the signature validates. Does this mean I’m safe from spoofing attacks?
Even if all our email is DKIM signed and validated by all ISPs, this is no time to rest. The world is full of ethically dubious people who want to impersonate us and steal our customers, and DKIM is only step one in protecting ourselves.
So what exactly is DKIM doing to help us with this? The way this standard ensures the integrity of our emails is to calculate a hash of the message’s body and some of its headers, and then to digitally sign the hash. As long as the private key is kept secure, and the public key is accessible through DNS, the DKIM signature gives ISPs confidence that the domain that signs the message acknowledges its content through the signature. Let’s have another look at the DKIM signature to see exactly what we’re talking about:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xtk53kxcy4p3t6ztbrffs6d54rsrrhh6; d=ses-example.com;
t=1366720445;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID;
bh=lcj/Sl5qKl6K6zwFUwb7Flgnngl892pW574kmS1hrS0=;
b=nhVMQLmSh7/DM5PW7xPV4K/PN4iVY0a5OF4YYk2L7jgUq9hHQlckopxe82TaAr64
eVTcBhHHj9Bwtzkmuk88g4G5UUN8J+AAsd/JUNGoZOBS1OofSkuAQ6cGfRGanF68Ag7
nmmEjEi+JL5JQh//u+EKTH4TVb4zdEWlBuMlrdTg=
The "d" tag represents the domain that signs the email. In this case that would be our own domain, ses-example.com. This domain takes responsibility for the email, guaranteeing its integrity through the signature. The "h" tag contains a list of all of the headers of this email that are signed (and thus have their integrity guaranteed) by the signing domain. The "bh" tag is the result of a hash function applied to the email’s body (very useful to ensure that the content itself hasn’t been tampered with). Finally, the "b" tag is the actual signature itself, applied to the body hash and headers. If that checks out, then both the message body and all of the headers included in the "h" tag are considered to be authenticated by the signing domain.
That’s all very nice, but how does it stop an attacker?
The hashing and key encryption algorithms we use are well known, so surely anyone can generate their own key pair and calculate the signature themselves, right? In fact… this is actually true. Anyone can sign any email with a DKIM signature, the problem is getting ISPs to trust that that signature is ours and not the attacker’s. The key here is in the "s" and "d" tags of the signature. The "d" tag is our domain, and the "s" (or "selector") tag indicates which of our domain’s signing keys has been used for this particular email. It’s these two tags that help build the location of the public key in DNS and form the obstacle in the attacker’s path. In this signature’s case, any ISP that wants to validate our email will try to retrieve the public key from a record xtk53kxcy4p3t6ztbrffs6d54rsrrhh6._domainkey.ses-example.com ( <selector>._domainkey.<domain> ). An attacker can calculate hashes and signatures all they want but they won’t have permission to publish any key they control into our DNS, so they will never be able to compute a signature that has our domain as the "d" tag (and thus has its integrity guaranteed by us). DNS spoofing, it turns out, is not so easy to perform (although it has happened)! With only the public key visible in DNS, it is not computationally easy for any attacker to deduce the private part. Just in case, SES regularly rotates the keys, to thwart any such attempt.
Setting up DMARC can also signal ISPs to drop all emails that aren’t authenticated (via DKIM or SPF). If an attacker wants to impersonate our domain they can either put in a broken signature or no signature at all. In both cases, DMARC signals ISPs to quarantine (put in the Spam folder) or drop those emails. That is definitely a good step forward in dealing with phishing spam!
SES also offers other forms of authentication such as SPF, which are highly recommended and will further improve our security.
Next Steps
In the next blog entry, we will have a look at another email-related concept that is indirectly influenced by DKIM: deliverability.

systemd Status Update

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-update-3.html

It
has been way too long since my last status update on
systemd
. Here’s another short, incomprehensive status update on
what we worked on for systemd since
then.

We have been working hard to turn systemd into the most viable set
of components to build operating systems, appliances and devices from,
and make it the best choice for servers, for desktops and for embedded
environments alike. I think we have a really convincing set of
features now, but we are actively working on making it even
better.

Here’s a list of some more and some less interesting features, in
no particular order:

We added an automatic pager to systemctl (and related tools), similar
to how git has it.

systemctl learnt a new switch –failed, to show only
failed services.

You may now start services immediately, overrding all dependency
logic by passing –ignore-dependencies to
systemctl. This is mostly a debugging tool and nothing people
should use in real life.

Sending SIGKILL as final part of the implicit shutdown
logic of services is now optional and may be configured with the
SendSIGKILL= option individually for each service.

We split off the Vala/Gtk tools into its own project systemd-ui.

systemd-tmpfiles learnt file globbing and creating FIFO
special files as well as character and block device nodes, and
symlinks. It also is capable of relabelling certain directories at
boot now (in the SELinux sense).

Immediately before shuttding dow we will now invoke all binaries
found in /lib/systemd/system-shutdown/, which is useful for
debugging late shutdown.

You may now globally control where STDOUT/STDERR of services goes
(unless individual service configuration overrides it).

There’s a new ConditionVirtualization= option, that makes
systemd skip a specific service if a certain virtualization technology
is found or not found. Similar, we now have a new option to detect
whether a certain security technology (such as SELinux) is available,
called ConditionSecurity=. There’s also
ConditionCapability= to check whether a certain process
capability is in the capability bounding set of the system. There’s
also a new ConditionFileIsExecutable=,
ConditionPathIsMountPoint=,
ConditionPathIsReadWrite=,
ConditionPathIsSymbolicLink=.

The file system condition directives now support globbing.

Service conditions may now be “triggering” and “mandatory”, meaning that
they can be a necessary requirement to hold for a service to start, or
simply one trigger among many.

At boot time we now print warnings if: /usr
is on a split-off partition but not already mounted by an initrd
;
if /etc/mtab is not a symlink to /proc/mounts; CONFIG_CGROUPS
is not enabled in the kernel
. We’ll also expose this as
tainted flag on the bus.

You may now boot the same OS image on a bare metal machine and in
Linux namespace containers and will get a clean boot in both
cases. This is more complicated than it sounds since device management
with udev or write access to /sys, /proc/sys or
things like /dev/kmsg is not available in a container. This
makes systemd a first-class choice for managing thin container
setups. This is all tested with systemd’s own systemd-nspawn
tool but should work fine in LXC setups, too. Basically this means
that you do not have to adjust your OS manually to make it work in a
container environment, but will just work out of the box. It also
makes it easier to convert real systems into containers.

We now automatically spawn gettys on HVC ttys when booting in VMs.

We introduced /etc/machine-id as a generalization of
D-Bus machine ID logic. See this
blog story for more information
. On stateless/read-only systems
the machine ID is initialized randomly at boot. In virtualized
environments it may be passed in from the machine manager (with qemu’s
-uuid switch, or via the container
interface
).

All of the systemd-specific /etc/fstab mount options are
now in the x-systemd-xyz format.

To make it easy to find non-converted services we will now
implicitly prefix all LSB and SysV init script descriptions with the
strings “LSB:” resp. “SYSV:”.

We introduced /run and made it a hard dependency of
systemd. This directory is now widely accepted and implemented on all
relevant Linux distributions.

systemctl can now execute all its operations remotely too (-H switch).

We now ship systemd-nspawn,
a really powerful tool that can be used to start containers for
debugging, building and testing, much like chroot(1). It is useful to
just get a shell inside a build tree, but is good enough to boot up a
full system in it, too.

If we query the user for a hard disk password at boot he may hit
TAB to hide the asterisks we normally show for each key that is
entered, for extra paranoia.

We don’t enable udev-settle.service anymore, which is
only required for certain legacy software that still hasn’t been
updated to follow devices coming and going cleanly.

We now include a tool that can plot boot speed graphs, similar to
bootchartd, called systemd-analyze.

At boot, we now initialize the kernel’s binfmt_misc logic with the data from /etc/binfmt.d.

systemctl now recognizes if it is run in a chroot()
environment and will work accordingly (i.e. apply changes to the tree
it is run in, instead of talking to the actual PID 1 for this). It also has a new –root= switch to work on an OS tree from outside of it.

There’s a new unit dependency type OnFailureIsolate= that
allows entering a different target whenever a certain unit fails. For
example, this is interesting to enter emergency mode if file system
checks of crucial file systems failed.

Socket units may now listen on Netlink sockets, special files
from /proc and POSIX message queues, too.

There’s a new IgnoreOnIsolate= flag which may be used to
ensure certain units are left untouched by isolation requests. There’s
a new IgnoreOnSnapshot= flag which may be used to exclude
certain units from snapshot units when they are created.

There’s now small mechanism services for
changing the local hostname and other host meta data
, changing
the system locale and console settings
and the system
clock
.

We now limit the capability bounding set for a number of our
internal services by default.

Plymouth may now be disabled globally with
plymouth.enable=0 on the kernel command line.

We now disallocate VTs when a getty finished running (and
optionally other tools run on VTs). This adds extra security since it
clears up the scrollback buffer so that subsequent users cannot get
access to a user’s session output.

In socket units there are now options to control the
IP_TRANSPARENT, SO_BROADCAST, SO_PASSCRED,
SO_PASSSEC socket options.

The receive and send buffers of socket units may now be set larger
than the default system settings if needed by using
SO_{RCV,SND}BUFFORCE.

We now set the hardware timezone as one of the first things in PID
1, in order to avoid time jumps during normal userspace operation, and
to guarantee sensible times on all generated logs. We also no longer
save the system clock to the RTC on shutdown, assuming that this is
done by the clock control tool when the user modifies the time, or
automatically by the kernel if NTP is enabled.

The SELinux directory got moved from /selinux to
/sys/fs/selinux.

We added a small service systemd-logind that keeps tracks
of logged in users and their sessions. It creates control groups for
them, implements the XDG_RUNTIME_DIR
specification
for them, maintains seats and device node ACLs and
implements shutdown/idle inhibiting for clients. It auto-spawns gettys
on all local VTs when the user switches to them (instead of starting
six of them unconditionally), thus reducing the resource foot print by
default. It has a D-Bus interface as well as a
simple synchronous library interface
. This mechanism obsoletes
ConsoleKit which is now deprecated and should no longer be used.

There’s now full, automatic multi-seat support, and this is
enabled in GNOME 3.4. Just by pluging in new seat hardware you get a
new login screen on your seat’s screen.

There is now an option ControlGroupModify= to allow
services to change the properties of their control groups dynamically,
and one to make control groups persistent in the tree
(ControlGroupPersistent=) so that they can be created and
maintained by external tools.

We now jump back into the initrd in shutdown, so that it can
detach the root file system and the storage devices backing it. This
allows (for the first time!) to reliably undo complex storage setups
on shutdown and leave them in a clean state.

systemctl now supports presets, a way for distributions and
administrators to define their own policies on whether services should
be enabled or disabled by default on package installation.

systemctl now has high-level verbs for masking/unmasking
units. There’s also a new command (systemctl list-unit-files)
for determining the list of all installed unit file files and whether
they are enabled or not.

We now apply sysctl variables to each new network device, as it
appears. This makes /etc/sysctl.d compatible with hot-plug
network devices.

There’s limited profiling for SELinux start-up perfomance built
into PID 1.

There’s a new switch PrivateNetwork=
to turn of any network access for a specific service.

Service units may now include configuration for control group
parameters. A few (such as MemoryLimit=) are exposed with
high-level options, and all others are available via the generic
ControlGroupAttribute= setting.

There’s now the option to mount certain cgroup controllers
jointly at boot. We do this now for cpu and
cpuacct by default.

We added the
journal
and turned it on by default.

All service output is now written to the Journal by default,
regardless whether it is sent via syslog or simply written to
stdout/stderr. Both message streams end up in the same location and
are interleaved the way they should. All log messages even from the
kernel and from early boot end up in the journal. Now, no service
output gets unnoticed and is saved and indexed at the same
location.

systemctl status will now show the last 10 log lines for
each service, directly from the journal.

We now show the progress of fsck at boot on the console,
again. We also show the much loved colorful [ OK ] status
messages at boot again, as known from most SysV implementations.

We merged udev into systemd.

We implemented and documented interfaces to container
managers
and initrds
for passing execution data to systemd. We also implemented and
documented an
interface for storage daemons that are required to back the root file
system
.

There are two new options in service files to propagate reload requests between several units.

systemd-cgls won’t show kernel threads by default anymore, or show empty control groups.

We added a new tool systemd-cgtop that shows resource
usage of whole services in a top(1) like fasion.

systemd may now supervise services in watchdog style. If enabled
for a service the daemon daemon has to ping PID 1 in regular intervals
or is otherwise considered failed (which might then result in
restarting it, or even rebooting the machine, as configured). Also,
PID 1 is capable of pinging a hardware watchdog. Putting this
together, the hardware watchdogs PID 1 and PID 1 then watchdogs
specific services. This is highly useful for high-availability servers
as well as embedded machines. Since watchdog hardware is noawadays
built into all modern chipsets (including desktop chipsets), this
should hopefully help to make this a more widely used
functionality.

We added support for a new kernel command line option
systemd.setenv= to set an environment variable
system-wide.

By default services which are started by systemd will have SIGPIPE
set to ignored. The Unix SIGPIPE logic is used to reliably implement
shell pipelines and when left enabled in services is usually just a
source of bugs and problems.

You may now configure the rate limiting that is applied to
restarts of specific services. Previously the rate limiting parameters
were hard-coded (similar to SysV).

There’s now support for loading the IMA integrity policy into the
kernel early in PID 1, similar to how we already did it with the
SELinux policy.

There’s now an official API to schedule and query scheduled shutdowns.

We changed the license from GPL2+ to LGPL2.1+.

We made systemd-detect-virt
an official tool in the tool set. Since we already had code to detect
certain VM and container environments we now added an official tool
for administrators to make use of in shell scripts and suchlike.

We documented numerous
interfaces
systemd introduced.

Much of the stuff above is already available in Fedora 15 and 16,
or will be made available in the upcoming Fedora 17.

And that’s it for now. There’s a lot of other stuff in the git commits, but
most of it is smaller and I will it thus spare you.

I’d like to thank everybody who contributed to systemd over the past years.

Thanks for your interest!

systemd Status Update

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-update-3.html

It
has been way too long since my last status update on
systemd
. Here’s another short, incomprehensive status update on
what we worked on for systemd since
then.

We have been working hard to turn systemd into the most viable set
of components to build operating systems, appliances and devices from,
and make it the best choice for servers, for desktops and for embedded
environments alike. I think we have a really convincing set of
features now, but we are actively working on making it even
better.

Here’s a list of some more and some less interesting features, in
no particular order:

  1. We added an automatic pager to systemctl (and related tools), similar
    to how git has it.
  2. systemctl learnt a new switch --failed, to show only
    failed services.
  3. You may now start services immediately, overrding all dependency
    logic by passing --ignore-dependencies to
    systemctl. This is mostly a debugging tool and nothing people
    should use in real life.
  4. Sending SIGKILL as final part of the implicit shutdown
    logic of services is now optional and may be configured with the
    SendSIGKILL= option individually for each service.
  5. We split off the Vala/Gtk tools into its own project systemd-ui.
  6. systemd-tmpfiles learnt file globbing and creating FIFO
    special files as well as character and block device nodes, and
    symlinks. It also is capable of relabelling certain directories at
    boot now (in the SELinux sense).
  7. Immediately before shuttding dow we will now invoke all binaries
    found in /lib/systemd/system-shutdown/, which is useful for
    debugging late shutdown.
  8. You may now globally control where STDOUT/STDERR of services goes
    (unless individual service configuration overrides it).
  9. There’s a new ConditionVirtualization= option, that makes
    systemd skip a specific service if a certain virtualization technology
    is found or not found. Similar, we now have a new option to detect
    whether a certain security technology (such as SELinux) is available,
    called ConditionSecurity=. There’s also
    ConditionCapability= to check whether a certain process
    capability is in the capability bounding set of the system. There’s
    also a new ConditionFileIsExecutable=,
    ConditionPathIsMountPoint=,
    ConditionPathIsReadWrite=,
    ConditionPathIsSymbolicLink=.
  10. The file system condition directives now support globbing.
  11. Service conditions may now be “triggering” and “mandatory”, meaning that
    they can be a necessary requirement to hold for a service to start, or
    simply one trigger among many.
  12. At boot time we now print warnings if: /usr
    is on a split-off partition but not already mounted by an initrd
    ;
    if /etc/mtab is not a symlink to /proc/mounts; CONFIG_CGROUPS
    is not enabled in the kernel
    . We’ll also expose this as
    tainted flag on the bus.
  13. You may now boot the same OS image on a bare metal machine and in
    Linux namespace containers and will get a clean boot in both
    cases. This is more complicated than it sounds since device management
    with udev or write access to /sys, /proc/sys or
    things like /dev/kmsg is not available in a container. This
    makes systemd a first-class choice for managing thin container
    setups. This is all tested with systemd’s own systemd-nspawn
    tool but should work fine in LXC setups, too. Basically this means
    that you do not have to adjust your OS manually to make it work in a
    container environment, but will just work out of the box. It also
    makes it easier to convert real systems into containers.
  14. We now automatically spawn gettys on HVC ttys when booting in VMs.
  15. We introduced /etc/machine-id as a generalization of
    D-Bus machine ID logic. See this
    blog story for more information
    . On stateless/read-only systems
    the machine ID is initialized randomly at boot. In virtualized
    environments it may be passed in from the machine manager (with qemu’s
    -uuid switch, or via the container
    interface
    ).
  16. All of the systemd-specific /etc/fstab mount options are
    now in the x-systemd-xyz format.
  17. To make it easy to find non-converted services we will now
    implicitly prefix all LSB and SysV init script descriptions with the
    strings “LSB:” resp. “SYSV:“.
  18. We introduced /run and made it a hard dependency of
    systemd. This directory is now widely accepted and implemented on all
    relevant Linux distributions.
  19. systemctl can now execute all its operations remotely too (-H switch).
  20. We now ship systemd-nspawn,
    a really powerful tool that can be used to start containers for
    debugging, building and testing, much like chroot(1). It is useful to
    just get a shell inside a build tree, but is good enough to boot up a
    full system in it, too.
  21. If we query the user for a hard disk password at boot he may hit
    TAB to hide the asterisks we normally show for each key that is
    entered, for extra paranoia.
  22. We don’t enable udev-settle.service anymore, which is
    only required for certain legacy software that still hasn’t been
    updated to follow devices coming and going cleanly.
  23. We now include a tool that can plot boot speed graphs, similar to
    bootchartd, called systemd-analyze.
  24. At boot, we now initialize the kernel’s binfmt_misc logic with the data from /etc/binfmt.d.
  25. systemctl now recognizes if it is run in a chroot()
    environment and will work accordingly (i.e. apply changes to the tree
    it is run in, instead of talking to the actual PID 1 for this). It also has a new --root= switch to work on an OS tree from outside of it.
  26. There’s a new unit dependency type OnFailureIsolate= that
    allows entering a different target whenever a certain unit fails. For
    example, this is interesting to enter emergency mode if file system
    checks of crucial file systems failed.
  27. Socket units may now listen on Netlink sockets, special files
    from /proc and POSIX message queues, too.
  28. There’s a new IgnoreOnIsolate= flag which may be used to
    ensure certain units are left untouched by isolation requests. There’s
    a new IgnoreOnSnapshot= flag which may be used to exclude
    certain units from snapshot units when they are created.
  29. There’s now small mechanism services for
    changing the local hostname and other host meta data
    , changing
    the system locale and console settings
    and the system
    clock
    .
  30. We now limit the capability bounding set for a number of our
    internal services by default.
  31. Plymouth may now be disabled globally with
    plymouth.enable=0 on the kernel command line.
  32. We now disallocate VTs when a getty finished running (and
    optionally other tools run on VTs). This adds extra security since it
    clears up the scrollback buffer so that subsequent users cannot get
    access to a user’s session output.
  33. In socket units there are now options to control the
    IP_TRANSPARENT, SO_BROADCAST, SO_PASSCRED,
    SO_PASSSEC socket options.
  34. The receive and send buffers of socket units may now be set larger
    than the default system settings if needed by using
    SO_{RCV,SND}BUFFORCE.
  35. We now set the hardware timezone as one of the first things in PID
    1, in order to avoid time jumps during normal userspace operation, and
    to guarantee sensible times on all generated logs. We also no longer
    save the system clock to the RTC on shutdown, assuming that this is
    done by the clock control tool when the user modifies the time, or
    automatically by the kernel if NTP is enabled.
  36. The SELinux directory got moved from /selinux to
    /sys/fs/selinux.
  37. We added a small service systemd-logind that keeps tracks
    of logged in users and their sessions. It creates control groups for
    them, implements the XDG_RUNTIME_DIR
    specification
    for them, maintains seats and device node ACLs and
    implements shutdown/idle inhibiting for clients. It auto-spawns gettys
    on all local VTs when the user switches to them (instead of starting
    six of them unconditionally), thus reducing the resource foot print by
    default. It has a D-Bus interface as well as a
    simple synchronous library interface
    . This mechanism obsoletes
    ConsoleKit which is now deprecated and should no longer be used.
  38. There’s now full, automatic multi-seat support, and this is
    enabled in GNOME 3.4. Just by pluging in new seat hardware you get a
    new login screen on your seat’s screen.
  39. There is now an option ControlGroupModify= to allow
    services to change the properties of their control groups dynamically,
    and one to make control groups persistent in the tree
    (ControlGroupPersistent=) so that they can be created and
    maintained by external tools.
  40. We now jump back into the initrd in shutdown, so that it can
    detach the root file system and the storage devices backing it. This
    allows (for the first time!) to reliably undo complex storage setups
    on shutdown and leave them in a clean state.
  41. systemctl now supports presets, a way for distributions and
    administrators to define their own policies on whether services should
    be enabled or disabled by default on package installation.
  42. systemctl now has high-level verbs for masking/unmasking
    units. There’s also a new command (systemctl list-unit-files)
    for determining the list of all installed unit file files and whether
    they are enabled or not.
  43. We now apply sysctl variables to each new network device, as it
    appears. This makes /etc/sysctl.d compatible with hot-plug
    network devices.
  44. There’s limited profiling for SELinux start-up perfomance built
    into PID 1.
  45. There’s a new switch PrivateNetwork=
    to turn of any network access for a specific service.
  46. Service units may now include configuration for control group
    parameters. A few (such as MemoryLimit=) are exposed with
    high-level options, and all others are available via the generic
    ControlGroupAttribute= setting.
  47. There’s now the option to mount certain cgroup controllers
    jointly at boot. We do this now for cpu and
    cpuacct by default.
  48. We added the
    journal
    and turned it on by default.
  49. All service output is now written to the Journal by default,
    regardless whether it is sent via syslog or simply written to
    stdout/stderr. Both message streams end up in the same location and
    are interleaved the way they should. All log messages even from the
    kernel and from early boot end up in the journal. Now, no service
    output gets unnoticed and is saved and indexed at the same
    location.
  50. systemctl status will now show the last 10 log lines for
    each service, directly from the journal.
  51. We now show the progress of fsck at boot on the console,
    again. We also show the much loved colorful [ OK ] status
    messages at boot again, as known from most SysV implementations.
  52. We merged udev into systemd.
  53. We implemented and documented interfaces to container
    managers
    and initrds
    for passing execution data to systemd. We also implemented and
    documented an
    interface for storage daemons that are required to back the root file
    system
    .
  54. There are two new options in service files to propagate reload requests between several units.
  55. systemd-cgls won’t show kernel threads by default anymore, or show empty control groups.
  56. We added a new tool systemd-cgtop that shows resource
    usage of whole services in a top(1) like fasion.
  57. systemd may now supervise services in watchdog style. If enabled
    for a service the daemon daemon has to ping PID 1 in regular intervals
    or is otherwise considered failed (which might then result in
    restarting it, or even rebooting the machine, as configured). Also,
    PID 1 is capable of pinging a hardware watchdog. Putting this
    together, the hardware watchdogs PID 1 and PID 1 then watchdogs
    specific services. This is highly useful for high-availability servers
    as well as embedded machines. Since watchdog hardware is noawadays
    built into all modern chipsets (including desktop chipsets), this
    should hopefully help to make this a more widely used
    functionality.
  58. We added support for a new kernel command line option
    systemd.setenv= to set an environment variable
    system-wide.
  59. By default services which are started by systemd will have SIGPIPE
    set to ignored. The Unix SIGPIPE logic is used to reliably implement
    shell pipelines and when left enabled in services is usually just a
    source of bugs and problems.
  60. You may now configure the rate limiting that is applied to
    restarts of specific services. Previously the rate limiting parameters
    were hard-coded (similar to SysV).
  61. There’s now support for loading the IMA integrity policy into the
    kernel early in PID 1, similar to how we already did it with the
    SELinux policy.
  62. There’s now an official API to schedule and query scheduled shutdowns.
  63. We changed the license from GPL2+ to LGPL2.1+.
  64. We made systemd-detect-virt
    an official tool in the tool set. Since we already had code to detect
    certain VM and container environments we now added an official tool
    for administrators to make use of in shell scripts and suchlike.
  65. We documented numerous
    interfaces
    systemd introduced.

Much of the stuff above is already available in Fedora 15 and 16,
or will be made available in the upcoming Fedora 17.

And that’s it for now. There’s a lot of other stuff in the git commits, but
most of it is smaller and I will it thus spare you.

I’d like to thank everybody who contributed to systemd over the past years.

Thanks for your interest!

systemd Status Update

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/systemd-update-3.html

It
has been way too long since my last status update on
systemd
. Here’s another short, incomprehensive status update on
what we worked on for systemd since
then.

We have been working hard to turn systemd into the most viable set
of components to build operating systems, appliances and devices from,
and make it the best choice for servers, for desktops and for embedded
environments alike. I think we have a really convincing set of
features now, but we are actively working on making it even
better.

Here’s a list of some more and some less interesting features, in
no particular order:

  1. We added an automatic pager to systemctl (and related tools), similar
    to how git has it.
  2. systemctl learnt a new switch --failed, to show only
    failed services.
  3. You may now start services immediately, overrding all dependency
    logic by passing --ignore-dependencies to
    systemctl. This is mostly a debugging tool and nothing people
    should use in real life.
  4. Sending SIGKILL as final part of the implicit shutdown
    logic of services is now optional and may be configured with the
    SendSIGKILL= option individually for each service.
  5. We split off the Vala/Gtk tools into its own project systemd-ui.
  6. systemd-tmpfiles learnt file globbing and creating FIFO
    special files as well as character and block device nodes, and
    symlinks. It also is capable of relabelling certain directories at
    boot now (in the SELinux sense).
  7. Immediately before shuttding dow we will now invoke all binaries
    found in /lib/systemd/system-shutdown/, which is useful for
    debugging late shutdown.
  8. You may now globally control where STDOUT/STDERR of services goes
    (unless individual service configuration overrides it).
  9. There’s a new ConditionVirtualization= option, that makes
    systemd skip a specific service if a certain virtualization technology
    is found or not found. Similar, we now have a new option to detect
    whether a certain security technology (such as SELinux) is available,
    called ConditionSecurity=. There’s also
    ConditionCapability= to check whether a certain process
    capability is in the capability bounding set of the system. There’s
    also a new ConditionFileIsExecutable=,
    ConditionPathIsMountPoint=,
    ConditionPathIsReadWrite=,
    ConditionPathIsSymbolicLink=.
  10. The file system condition directives now support globbing.
  11. Service conditions may now be “triggering” and “mandatory”, meaning that
    they can be a necessary requirement to hold for a service to start, or
    simply one trigger among many.
  12. At boot time we now print warnings if: /usr
    is on a split-off partition but not already mounted by an initrd
    ;
    if /etc/mtab is not a symlink to /proc/mounts; CONFIG_CGROUPS
    is not enabled in the kernel
    . We’ll also expose this as
    tainted flag on the bus.
  13. You may now boot the same OS image on a bare metal machine and in
    Linux namespace containers and will get a clean boot in both
    cases. This is more complicated than it sounds since device management
    with udev or write access to /sys, /proc/sys or
    things like /dev/kmsg is not available in a container. This
    makes systemd a first-class choice for managing thin container
    setups. This is all tested with systemd’s own systemd-nspawn
    tool but should work fine in LXC setups, too. Basically this means
    that you do not have to adjust your OS manually to make it work in a
    container environment, but will just work out of the box. It also
    makes it easier to convert real systems into containers.
  14. We now automatically spawn gettys on HVC ttys when booting in VMs.
  15. We introduced /etc/machine-id as a generalization of
    D-Bus machine ID logic. See this
    blog story for more information
    . On stateless/read-only systems
    the machine ID is initialized randomly at boot. In virtualized
    environments it may be passed in from the machine manager (with qemu’s
    -uuid switch, or via the container
    interface
    ).
  16. All of the systemd-specific /etc/fstab mount options are
    now in the x-systemd-xyz format.
  17. To make it easy to find non-converted services we will now
    implicitly prefix all LSB and SysV init script descriptions with the
    strings “LSB:” resp. “SYSV:“.
  18. We introduced /run and made it a hard dependency of
    systemd. This directory is now widely accepted and implemented on all
    relevant Linux distributions.
  19. systemctl can now execute all its operations remotely too (-H switch).
  20. We now ship systemd-nspawn,
    a really powerful tool that can be used to start containers for
    debugging, building and testing, much like chroot(1). It is useful to
    just get a shell inside a build tree, but is good enough to boot up a
    full system in it, too.
  21. If we query the user for a hard disk password at boot he may hit
    TAB to hide the asterisks we normally show for each key that is
    entered, for extra paranoia.
  22. We don’t enable udev-settle.service anymore, which is
    only required for certain legacy software that still hasn’t been
    updated to follow devices coming and going cleanly.
  23. We now include a tool that can plot boot speed graphs, similar to
    bootchartd, called systemd-analyze.
  24. At boot, we now initialize the kernel’s binfmt_misc logic with the data from /etc/binfmt.d.
  25. systemctl now recognizes if it is run in a chroot()
    environment and will work accordingly (i.e. apply changes to the tree
    it is run in, instead of talking to the actual PID 1 for this). It also has a new --root= switch to work on an OS tree from outside of it.
  26. There’s a new unit dependency type OnFailureIsolate= that
    allows entering a different target whenever a certain unit fails. For
    example, this is interesting to enter emergency mode if file system
    checks of crucial file systems failed.
  27. Socket units may now listen on Netlink sockets, special files
    from /proc and POSIX message queues, too.
  28. There’s a new IgnoreOnIsolate= flag which may be used to
    ensure certain units are left untouched by isolation requests. There’s
    a new IgnoreOnSnapshot= flag which may be used to exclude
    certain units from snapshot units when they are created.
  29. There’s now small mechanism services for
    changing the local hostname and other host meta data
    , changing
    the system locale and console settings
    and the system
    clock
    .
  30. We now limit the capability bounding set for a number of our
    internal services by default.
  31. Plymouth may now be disabled globally with
    plymouth.enable=0 on the kernel command line.
  32. We now disallocate VTs when a getty finished running (and
    optionally other tools run on VTs). This adds extra security since it
    clears up the scrollback buffer so that subsequent users cannot get
    access to a user’s session output.
  33. In socket units there are now options to control the
    IP_TRANSPARENT, SO_BROADCAST, SO_PASSCRED,
    SO_PASSSEC socket options.
  34. The receive and send buffers of socket units may now be set larger
    than the default system settings if needed by using
    SO_{RCV,SND}BUFFORCE.
  35. We now set the hardware timezone as one of the first things in PID
    1, in order to avoid time jumps during normal userspace operation, and
    to guarantee sensible times on all generated logs. We also no longer
    save the system clock to the RTC on shutdown, assuming that this is
    done by the clock control tool when the user modifies the time, or
    automatically by the kernel if NTP is enabled.
  36. The SELinux directory got moved from /selinux to
    /sys/fs/selinux.
  37. We added a small service systemd-logind that keeps tracks
    of logged in users and their sessions. It creates control groups for
    them, implements the XDG_RUNTIME_DIR
    specification
    for them, maintains seats and device node ACLs and
    implements shutdown/idle inhibiting for clients. It auto-spawns gettys
    on all local VTs when the user switches to them (instead of starting
    six of them unconditionally), thus reducing the resource foot print by
    default. It has a D-Bus interface as well as a
    simple synchronous library interface
    . This mechanism obsoletes
    ConsoleKit which is now deprecated and should no longer be used.
  38. There’s now full, automatic multi-seat support, and this is
    enabled in GNOME 3.4. Just by pluging in new seat hardware you get a
    new login screen on your seat’s screen.
  39. There is now an option ControlGroupModify= to allow
    services to change the properties of their control groups dynamically,
    and one to make control groups persistent in the tree
    (ControlGroupPersistent=) so that they can be created and
    maintained by external tools.
  40. We now jump back into the initrd in shutdown, so that it can
    detach the root file system and the storage devices backing it. This
    allows (for the first time!) to reliably undo complex storage setups
    on shutdown and leave them in a clean state.
  41. systemctl now supports presets, a way for distributions and
    administrators to define their own policies on whether services should
    be enabled or disabled by default on package installation.
  42. systemctl now has high-level verbs for masking/unmasking
    units. There’s also a new command (systemctl list-unit-files)
    for determining the list of all installed unit file files and whether
    they are enabled or not.
  43. We now apply sysctl variables to each new network device, as it
    appears. This makes /etc/sysctl.d compatible with hot-plug
    network devices.
  44. There’s limited profiling for SELinux start-up perfomance built
    into PID 1.
  45. There’s a new switch PrivateNetwork=
    to turn of any network access for a specific service.
  46. Service units may now include configuration for control group
    parameters. A few (such as MemoryLimit=) are exposed with
    high-level options, and all others are available via the generic
    ControlGroupAttribute= setting.
  47. There’s now the option to mount certain cgroup controllers
    jointly at boot. We do this now for cpu and
    cpuacct by default.
  48. We added the
    journal
    and turned it on by default.
  49. All service output is now written to the Journal by default,
    regardless whether it is sent via syslog or simply written to
    stdout/stderr. Both message streams end up in the same location and
    are interleaved the way they should. All log messages even from the
    kernel and from early boot end up in the journal. Now, no service
    output gets unnoticed and is saved and indexed at the same
    location.
  50. systemctl status will now show the last 10 log lines for
    each service, directly from the journal.
  51. We now show the progress of fsck at boot on the console,
    again. We also show the much loved colorful [ OK ] status
    messages at boot again, as known from most SysV implementations.
  52. We merged udev into systemd.
  53. We implemented and documented interfaces to container
    managers
    and initrds
    for passing execution data to systemd. We also implemented and
    documented an
    interface for storage daemons that are required to back the root file
    system
    .
  54. There are two new options in service files to propagate reload requests between several units.
  55. systemd-cgls won’t show kernel threads by default anymore, or show empty control groups.
  56. We added a new tool systemd-cgtop that shows resource
    usage of whole services in a top(1) like fasion.
  57. systemd may now supervise services in watchdog style. If enabled
    for a service the daemon daemon has to ping PID 1 in regular intervals
    or is otherwise considered failed (which might then result in
    restarting it, or even rebooting the machine, as configured). Also,
    PID 1 is capable of pinging a hardware watchdog. Putting this
    together, the hardware watchdogs PID 1 and PID 1 then watchdogs
    specific services. This is highly useful for high-availability servers
    as well as embedded machines. Since watchdog hardware is noawadays
    built into all modern chipsets (including desktop chipsets), this
    should hopefully help to make this a more widely used
    functionality.
  58. We added support for a new kernel command line option
    systemd.setenv= to set an environment variable
    system-wide.
  59. By default services which are started by systemd will have SIGPIPE
    set to ignored. The Unix SIGPIPE logic is used to reliably implement
    shell pipelines and when left enabled in services is usually just a
    source of bugs and problems.
  60. You may now configure the rate limiting that is applied to
    restarts of specific services. Previously the rate limiting parameters
    were hard-coded (similar to SysV).
  61. There’s now support for loading the IMA integrity policy into the
    kernel early in PID 1, similar to how we already did it with the
    SELinux policy.
  62. There’s now an official API to schedule and query scheduled shutdowns.
  63. We changed the license from GPL2+ to LGPL2.1+.
  64. We made systemd-detect-virt
    an official tool in the tool set. Since we already had code to detect
    certain VM and container environments we now added an official tool
    for administrators to make use of in shell scripts and suchlike.
  65. We documented numerous
    interfaces
    systemd introduced.

Much of the stuff above is already available in Fedora 15 and 16,
or will be made available in the upcoming Fedora 17.

And that’s it for now. There’s a lot of other stuff in the git commits, but
most of it is smaller and I will it thus spare you.

I’d like to thank everybody who contributed to systemd over the past years.

Thanks for your interest!

Ok, Be Afraid if Someone’s Got a Voltmeter Hooked to Your CPU

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/05/crypto-fear.html

Boy, do I hate it when a
FLOSS
project is given a hard time unfairly. I was this morning greeted
with news
from many
places that OpenSSL, one of the
most common FLOSS software libraries used for cryptography, was
somehow severely vulnerable.

I had a hunch what was going on. I quickly downloaded
a copy
of the academic paper
that was cited as the sole source for the
story and read it. As I feared, OpenSSL was getting some bad press
unfairly. One must really read this academic computer science article
in the context it was written; most commenting about this paper
probably did not.

First of all, I don’t claim to be an expert on cryptography, and I
think my knowledge level to opine on this subject remains limited to a
little blog post like this and nothing more. Between college and
graduate school, I worked as a system administrator focusing on network
security. While a computer science graduate student, I did take two
cryptography courses, two theory of computation courses, and one class
on complexity theory0. So, when
compared to the general population I probably am an expert, but compared to
people who actually work in cryptography regularly, I’m clearly a
novice. However, I suspect many who have hitherto opined about this
academic article to declare this severe vulnerability have even
less knowledge than I do on the subject.

This article, of course, wasn’t written for novices like me, and
certainly not for the general public nor the technology press. It was
written by and for professional researchers who spend much time each
week reading dozens of these academic papers, a task I haven’t done
since graduate school. Indeed, the paper is written in a style I know
well; my “welcome to CS graduate school” seminar in 1997
covered the format well.

The first thing you have to note about such papers is that informed
readers generally ignore the parts that a newbie is most likely focus
on: the Abstract, Introduction and Conclusion sections. These sections
are promotional materials; they are equivalent to a sales brochure
selling you on how important and groundbreaking the research is. Some
research is groundbreaking, of course, but most is an incremental step
forward toward understanding some theoretical concept, or some report
about an isolated but interesting experimental finding.

Unfortunately, these promotional parts of the paper are the sections
that focus on the negative implications for OpenSSL. In the rest of the
paper, OpenSSL is merely the software component of the experiment
equipment. They likely could have used GNU TLS or any other
implementation of RSA taken from a book on
cryptography1. But this fact
is not even the primary reason that this article isn’t really that big
of a deal for daily use of cryptography.

The experiment described in the paper is very difficult to reproduce.
You have to cause very subtle faults in computation at specific times.
As I understand it, they had to assemble a specialized hardware copy of
a SPARC-based GNU/Linux environment to accomplish the experiment.

Next, the data generated during the run of the software on the
specially-constructed faulty hardware must be collected and operated
upon by a parallel processing computing environment over the course of
many hours. If it turns out all the needed data was gathered, the
output of this whole process is the private RSA key.

The details of the fault generation process deserve special mention.
Very specific faults have to occur, and they can’t occur such that any
other parts of the computation (such as, say, the normal running of the
operating system) are interrupted or corrupted. This is somewhat
straightforward to get done in a lab environment, but accomplishing it
in a production situation would be impractical and improbable. It would
also usually require physical access to the hardware holding the private
key. Such physical access would, of course, probably give you the
private key anyway by simply copying it off the hard drive or out of
RAM!

This is interesting research, and it does suggest some changes that
might be useful. For example, if it doesn’t slow a system down too
much, the integrity of RSA signatures should be verified, on a closely
controlled proxy unit with a separate CPU, before sending out to a wider
audience. But even that would be a process only for the most paranoid.
If faults are occurring on production hardware enough to generate the
bad computations this cracking process relies on, likely something else
will go wrong on the hardware too and it will be declared generally
unusable for production before an interloper could gather enough data to
crack the key. Thus, another useful change to make based on this
finding is to disable and discard RSA keys that were in use on
production hardware that went faulty.

Finally, I think this article does completely convince me that I would
never want to run any RSA computations on a system where the CPU was
emulated. Causing faults in an emulated CPU would only require changes
to the emulation software, and could be done with careful precision to
detect when an RSA-related computation was happening, and only give the
faulty result on those occasions. I’ve never heard of anyone running
production cryptography on an emulated CPU, since it would be too slow,
and virtualization technologies like Xen, KVM, and QEMU all
pass-through CPU instructions directly to hardware (for speed reasons)
when the virtualized guest matches the hardware architecture of the
host.

The point, however, is that proper description of the dangers of a
“security vulnerability” requires more than a single bit
field. Some security vulnerabilities are much worse than others. This
one is substantially closer to the “oh, that’s cute” end of
the spectrum, not the “ZOMG, everyone’s going to experience
identity theft tomorrow” side.

0Many casual
users don’t realize that cryptography — the stuff that secures your
networked data from unwanted viewers — isn’t about math problems
that are unsolvable. In fact, it’s often based on math problems that are
trivially solvable, but take a very long time to solve. This is why
algorithmic complexity questions are central to the question of
cryptographic security.

1 I’m
oversimplifying a bit here. A key factor in the paper appears to be the
linear time algorithm used to compute cryptographic digital signatures,
and the fact that the signatures aren’t verified for integrity before
being deployed. I suspect, though, that just about any RSA system is
going to do this. (Although I do usually test the integrity of my GnuPG
signatures before sending them out, I do this as a user by hand).