Category Archives: Encryption
Note: By default, an instance type that includes an NVMe instance store encrypts data at rest using an XTS-AES-256 block cipher. See this FAQ about NVMe-supported instance types. If youre using an NVMw instance type, then data at rest is encrypted by default, and this post doesnt apply to your situation.
Encrypting data at rest is vital for regulatory compliance to ensure that sensitive data saved on disks is not readable by any user or application without a valid key. Some compliance regulations such as PCI DSS and HIPAA require that data at rest be encrypted throughout the data lifecycle. To this end, AWS provides data-at-rest options and key management to support the encryption process. For example, you can encrypt Amazon EBS volumes and configure Amazon S3 buckets for server-side encryption (SSE) using AES-256 encryption. Additionally, Amazon RDS supports Transparent Data Encryption (TDE).
Instance storage provides temporary block-level storage for Amazon EC2 instances. This storage is located on disks attached physically to a host computer. Instance storage is ideal for temporary storage of information that frequently changes, such as buffers, caches, and scratch data. By default, files stored on these disks are not encrypted.
In this blog post, I show a method for encrypting data on Linux EC2 instance stores by using Linux built-in libraries. This method encrypts files transparently, which protects confidential data. As a result, applications that process the data are unaware of the disk-level encryption.
First, though, I will provide some background information required for this solution.
You can use two methods to encrypt files on instance stores. The first method is disk encryption, in which the entire disk or block within the disk is encrypted by using one or more encryption keys. Disk encryption operates below the file-system level, is operating-system agnostic, and hides directory and file information such as name and size. Encrypting File System, for example, is a Microsoft extension to the Windows NT operating systems New Technology File System (NTFS) that provides disk encryption.
The second method is file-system-level encryption. Files and directories are encrypted, but not the entire disk or partition. File-system-level encryption operates on top of the file system and is portable across operating systems.
Dm-crypt is a Linux kernel-level encryption mechanism that allows users to mount an encrypted file system. Mounting a file system is the process in which a file system is attached to a directory (mount point), making it available to the operating system. After mounting, all files in the file system are available to applications without any additional interaction; however, these files are encrypted when stored on disk.
Device mapper is an infrastructure in the Linux 2.6 and 3.x kernel that provides a generic way to create virtual layers of block devices. The device mapper crypt target provides transparent encryption of block devices using the kernel crypto API. The solution in this post uses dm-crypt in conjunction with a disk-backed file system mapped to a logical volume by the Logical Volume Manager (LVM). LVM provides logical volume management for the Linux kernel.
The following diagram depicts the relationship between an application, file system, and dm-crypt. Dm-crypt sits between the physical disk and the file system, and data written from the operating system to the disk is encrypted. The application is unaware of such disk-level encryption. Applications use a specific mount point in order to store and retrieve files, and these files are encrypted when stored to disk. If the disk is lost or stolen, the data on the disk is useless.
In this post, I create a new file system called secretfs. This file system is encrypted using dm-crypt. This example uses LVM and Linux Unified Key Setup (LUKS) to encrypt a file system. The encrypted file system sits on the EC2 instance store disk. Note that the internal store file system is not encrypted but rather a newly created file system.
The following diagram shows how the newly encrypted file system resides in the EC2 internal store disk. Applications that need to save sensitive data temporarily will use the secretfs mount point (/mnt/secretfs) directory to store temporary or scratch files.
This solution has three requirements for the solution to work. First, you need to configure the related items on boot using EC2 launch configuration because the encrypted file system is created at boot time. An administrator should have full control over every step and should be able to grant and revoke the encrypted file system creation or access to keys. Second, you must enable logging for every encryption or decryption request by using AWS CloudTrail. In particular, logging is critical when the keys are created and when an EC2 instance requests password decryption to unlock an encrypted file system. Lastly, you should integrate the solution with other AWS services, as described in the next section.
I use the following AWS services in this solution:
The following high-level architectural diagram illustrates the solution proposed in order to enable EC2 instance store encrypting. A detailed implementation plan follows in the next section.
In this architectural diagram:
First, you create a bucket for storing the file that holds the encrypted password. This password (key) will be used to encrypt the file system. Each EC2 instance upon boot copies the file, reads the encrypted password, decrypts the password, and retrieves the plaintext password, which is used to encrypt the file system on the instance store disk.
In this step, you create the S3 bucket that stores the encrypted password file, and apply the necessary permissions. If you are using an Amazon VPC endpoint for Amazon S3, you also need to add permissions to the bucket to allow access from the endpoint. (For a detailed example, see Example Bucket Policies for VPC Endpoints for Amazon S3.)
To create a new bucket:
When an EC2 instance boots, it must read the encrypted password file from S3 and then decrypt the password using KMS. In this section, I configure an IAM policy that allows the EC2 instance to assume a role with the right access permissions to the S3 bucket. The following policy grants the correct access permissions, in which your-bucket-name is the S3 bucket that stores the encrypted password file.
To create and configure the IAM policy:
The preceding policy grants read access to the bucket where the encrypted password is stored. This policy is used by the EC2 instance, which requires you to configure an IAM role. You will configure KMS permissions later in this post.
You now should have a new IAM role listed on the Roles page. ChooseRoles to list all roles in your account and then select the role you just created as shown in the following screenshot.
Next, you use KMS to encrypt a secret password. To encrypt text by using KMS, you must use AWS CLI. AWS CLI is installed by default on EC2 Amazon Linux instances and you caninstallit on Linux, Windows, or Mac computers.
To encrypt a secret password with KMS and store it in the S3 bucket:
The preceding commands encrypt the password (Base64 is used to decode the cipher text). The command outputs the results to a file called LuksInternalStorageKey. It also creates a key alias (key name) that makes it easy to identify different keys; the alias is called EncFSForEC2InternalStorageKey. The file is then copied to the S3 bucket I created earlier in this post.
Next, you grant the role access to the key you just created with KMS:
In this section, you launch a new EC2 instance with the new IAM role and a bootstrap script that executes the steps to encrypt the file system, as described earlier in the Architectural overview section:
You can list the encrypted file systems status. First, SSH to the EC2 instance using the key pair you used to launch the EC2 instance. (For more information about logging in to an EC2 instance using a key pair, see Getting Started with Amazon EC2 Linux Instances.) Then, run the following command as root.
As the commands results should show, the file system is encrypted with AES-256 using XTS mode. XTS is a configuration method that allows ciphers to work with large data streams, without the risk of compromising the provided security.
This blog post shows you how to encrypt a file system on EC2 instance storage by using built-in Linux libraries and drivers with LVM and LUKS, in conjunction with AWS services such as S3 and KMS. If your applications need temporary storage, you can use an EC2 internal disk that is physically attached to the host computer. The data on instance stores persists only during the lifetime of its associated instance. However, instance store volumes are not encrypted. This post provides a simple solution that balances between the speed and availability of instance stores and the need for encryption at rest when dealing with sensitive data.
If you have comments about this blog post, submit them in the Comments section below. If you have implementation questions about the solution in this post, please start a new thread on the EC2 forum.
Want more AWS Security news? Follow us on Twitter.
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
A transition in cryptographic technologies is underway. New algorithms for encryption, authentication, digital signatures, and key exchange are needed to meet escalating security and performance requirements. Many of the algorithms that are in extensive use today cannot scale well to meet these needs. RSA signatures and DH key exchange are increasingly inefficient as security levels rise, and CBC encryption performs poorly at high data rates. An encryption system such as an IPsec Virtual Private Network uses many different component algorithms, and the level of security that it provides is limited by the lowest security level of each of those components. What we need is a complete algorithm suite in which each component provides a consistently high level of security and can scale well to high throughput and high numbers of connections. The next generation of encryption technologies meets this need by using Elliptic Curve Cryptography (ECC) to replace RSA and DH, and using Galois/Counter Mode (GCM) of the Advanced Encryption Standard (AES) block cipher for high-speed authenticated encryption. More on these algorithms below, but first, some good news: the new ISR Integrated Services Module brings these next-generation encryption (NGE) technologies to IPsec Virtual Private Networks, providing a security level of 128 bits or more. These technologies are future proof: the use of NGE enables a system to meet the security requirements of the next decade, and to interoperate with future products that leverage NGE to meet scalability requirements. NGE is based on IETF standards, and meets the government requirements for cryptography stipulated in FIPS-140.
NGE uses new crypto algorithms because they will scale better going forward. This is analogous to the way that jets replaced propeller planes; incremental improvements in propeller-driven aircraft are always possible, but it was necessary to adopt turbojets to achieve significant advances in speed and efficiency.
The community that needs a new technology most leads its adoption. For instance, the transition from propellers to jet engines happened for military applications before jets were adopted for commercial use. Similarly, governments are leading the transition to next generation encryption. The U.S. government selected and recommended a set of cryptographic standards, called Suite B because it provides a complete suite of algorithms that are designed to meet future security needs. Suite B has been approved for protecting classified information at both the SECRET and TOP SECRET levels. Suite B sets a good direction for the future of network security, and the Suite B algorithms have been incorporated into many standards. (Cisco supported the development of some of these standards, including GCM authenticated encryption and implementation methods for ECC.) NGE uses the Suite B algorithms for two different reasons. First, it enables government customers to conform to the Suite B requirements. Second, Suite B offers the best technologies for future-proof cryptography, and is setting the trend for the industry. These are the best standards that one can implement today if the goal is to meet the security and scalability requirements ten years hence, or to interoperate with the crypto that will be deployed in that timescale.
A network encryption system must meet the networks requirements for high throughput, high numbers of connections, and low latency, while providing protection against sophisticated attacks. Cryptographic algorithms and key sizes are designed to make it economically infeasible for an attacker to break a cryptosystem. In principle, all algorithms are vulnerable to an exhaustive key search. In practice, this vulnerability holds only if an attacker can afford enough computing power to try every possible key. Encryption systems are designed to make exhaustive search too costly for an attacker, while also keeping down the cost of encryption. The same is true for all of the cryptographic components that are used to secure communications digital signatures, key establishment, and cryptographic hashing are all engineered so that attackers cant afford the computing resources that would be needed to break the system.
Every year, advances in computing lower the cost of processing and storage. These advances in computing accrue over the years and make it imperative to periodically move to larger key sizes. Because of Moores law, and a similar empirical law for storage costs, symmetric cryptographic keys need to grow by a bit every 18 months. In order for an encryption system to have a useful shelf life, and be able to securely interoperate with other devices throughout its operational lifespan, it should provide security ten or more years into the future. The use of good cryptography is more important now than ever before, due to the threat of well-funded and knowledgeable attackers.
A complete crypto suite includes algorithms for authenticated encryption, digital signatures, key establishment, cryptographic hashing. I touch on each of these below, to explain the need for technology changes. The Rivest-Shamir-Adleman (RSA) algorithms for encryption and digital signatures are less efficient at higher security levels, as is the integer-based Diffie-Hellman (DH). In technical terms, there are sub-exponential attacks that can be used against these algorithms, and thus their key sizes must be substantially increased to compensate for this fact. In practice, this means that RSA and DH are becoming less efficient every year.
Elliptic Curve Cryptography (ECC) replaces RSA signatures with the ECDSA algorithm, and replaces the DH key exchange with ECDH. ECDSA is an elliptic curve variant of the DSA algorithm, which has been a standard since 1994. ECDH is an elliptic curve variant of the classic Diffie-Hellman key exchange. DH and DSA are both based on the mathematical group of integers modulo a large prime number. The ECC variants replace that group with a different mathematical group that is defined by an elliptic curve. The advantage of ECC is that there are no sub-exponential attacks that work against ECC, which means that ECC can provide higher security at lower computational cost. The efficiency gain is especially pronounced as one turns the security knob up.
The AES block cipher is widely used today; it is efficient and provides a good security level. However, the Cipher Block Chaining (CBC) mode of operation for AES, which is commonly used for encryption, contains serialized operations that make it impossible to pipeline. Additionally, it does not provide authentication, and thus the data encrypted by CBC must also be authenticated using a message authentication code like HMAC. NGE improves on the combination of CBC and HMAC by using AES in the Galois/Counter Mode (GCM) of operation.
Fifteen years ago, it was considered a truism that encryption could not keep up with the fastest networks. Ten years ago, it was realized that the counter mode of operation (CTR) could keep up, but that did not resolve the need for data authentication. GCM solves this problem by incorporating an efficient authentication method, based on arithmetic over finite fields. GCM is an authenticated encryption algorithm; it provides both confidentiality and authenticity. Combing both these security services into a single algorithm improves both security and performance. (For instance, it prevents subtle attacks that exploit unauthenticated encryption, such as the recent BEAST attack against the TLS/SSL protocol and similar attacks.) AES-GCM is efficient even at very high data rates, because its design enables the use of full data pipelines and parallelism. Its efficiency is showcased by its use in the IEEE MACsec protocol, where it has kept up with 802.1 data rates of 10, 40, and even 100 gigabits per second without adding significant latency.
NGE follows Suite B and uses the SHA-2 family of hash functions. These functions replace the ubiquitous SHA-1 hash with SHA-256, SHA-384, and SHA-512. SHA-1 only targets an 80-bit security level, and has been shown to not meet that goal. If you are still using SHA-1, you should transition to SHA-256, which provides a 128-bit security level.
For more information about Ciscos offering for faster next-generation encryption, see the Cisco VPN Internal Service Module for the ISR G2 page.
Originally posted here:
Next Generation Encryption – blogs.cisco.com
Its no secret that we at DataShield are large proponents of data security. Not only are data breaches incredibly expensive, but there are also laws regarding data securitythat need to be followed if businesses want to avoid large fines.
And while we are obviously advocates of shredding hard drivesonce its time to get rid of your computer, doing that only guarantees the safety of your data once its time for new hard drives. So what about all the time in between?
Enter data encryption: a highly recommended way to keep your data out of the wrong hands the entire time its on your computer.
Encryption is a technique for transforming informationon a computer in such a way that it becomes unreadable. So, even if someone is able to gain access to a computer with personal data on it, they likely wont be able to do anything with the data unless they have complicated, expensive software or the original data key.
The basic function of encryption is essentially to translate normal text into ciphertext. Encryption can help ensure that data doesnt get read by the wrong people, but can also ensure that data isnt altered in transit, and verify the identity of the sender.
There are three different basic encryption methods, each with their own advantages (list courtesy of Wisegeek):
Any of these methods would likely prove sufficient for proper data security, and a quick Google search will reveal the multitude of software available for data encryption. Data encryption is a necessity (both for legal reasons and otherwise) when transmitting information like PHI, so no matter what method you choose, make sure youre doing everything you can to protect data.
Dont just stop with encryption, though. DataShield offers compliance consultingto ensure that all of your business data and policies are up-to-spec for local and federal laws.
Contact us today for more information on how DataShield can help your data stay safe through its entire life cycle, from its conception to its destruction, when your computer is finally thrown out.
Turtl uses encryption to protect your data in such a way that only you, andthose you choose, are able to view your data. Keep reading for a high-leveloverview of Turts encryption and how it protects you.
Simply put, encryption is the process of scrambling data. Generally, this isdone using a key which is usually a passphrase. The only way to de-scramblethe data is using that passphrase.
Turtls encryption works by generating a key for you based on youremail and password. This key is used to lock and unlock (or encrypt anddecrypt) your data and keep it private. All of the encryption in Turtl happensbefore any data leaves the app, meaning that even if someone is snooping in onyour connection or someone hacks our database, everything youve put into Turtlis just gibberish to them.
Without the keys that only you hold, your data is useless.
As mentioned, Turtl creates a key for you when you log in based on your emailand password. It wouldnt be very useful if you had to give people this key whenyou shared data with them because it would give them access to all your data.Instead, Turtl generates a new, random key for each object. This key is whatis sent to people when sharing, allowing them to unlock the specific item yousend them and nothing else.
Keys are stored one of two ways:
If youre looking for a more comprehensive look at how Turtl does encryption,check out the encryption specifics page of the docswhich goes over the ciphers, block modes, and other methods Turtl uses whenhandling your data.
Turtl has a feature that keeps you logged in if the app is closed and reopened.This feature may have security implications. Read more about the Stay logged infeature.
Here are some possible scenarios where Turtls security measures will fail you.We try to provide an exhaustive list so youre aware of the dangers of relyingon Turtl.
Companies can reduce the probability of a data breach and thus reduce the risk of fines in the future, if they chose to use encryption of personal data. The processing of personal data is naturally associated with a certain degree of risk. Especially nowadays, where cyber-attacks are nearly unavoidable for companies above a given size. Therefore, risk management plays an ever-larger role in IT security and data encryption is suited, among other means, for these companies.
In general, encryption refers to the procedure that converts clear text into a hashed code using a key, where the outgoing information only becomes readable again by using the correct key. This minimises the risk of an incident during data processing, as encrypted contents are basically unreadable for third parties who do not have the correct key. Encryption is the best way to protect data during transfer and one way to secure stored personal data. It also reduces the risk of abuse within a company, as access is limited only to authorised people with the right key.
The Regulation also recognizes these risks when processing personal data and places the responsibility on the controller and the processor in Art. 32(1) of the General Data Protection Regulation to implement appropriate technical and organisational measures to secure personal data. The GDPR deliberately does not define which specific technical and organisational measures are considered suitable in each case, in order to accommodate individual factors. However, it gives the controller a catalogue of criteria to be considered when choosing methods to secure personal data. Those are the state of the art, implementation costs and the nature, scope, context and purposes of the processing. In addition to these criteria, one always has to consider the severity of the risks to the rights and freedoms of the data subject and how likely those risks could manifest. This basically boils down to the following: The higher the risks involved in the data processing and the more likely these are to manifest, the stronger the taken security measures have to be and the more measures must be taken. Encryption as a concept is explicitly mentioned as one possible technical and organisational measure to secure data in the list of Art. 32(1) of the GDPR, which is not exhaustive. Again, the GDPR does not mention explicit encryption methods to accommodate for the fast-paced technological progress. When choosing a method one must also apply the criteria catalogue above. To answer the question of what is currently considered state of the art data protection officers usually rely on the definitions set out in information security standards like ISO/IEC 27001 or other national IT-security guidelines.
Encryption of personal data has additional benefits for controllers and/or order processors. For example, the loss of a state of the art encrypted mobile storage medium which holds personal data is not necessarily considered a data breach, which must be reported to the data protection authorities. In addition, if there is a data breach, the authorities must positively consider the use of encryption in their decision on whether and what amount a fine is imposed as per Art. 83(2)(c) of the GDPR.
“Encryption is not authentication” is common wisdom among cryptography experts, but it is only rarely whispered among developers whom aren’t also cryptography experts. This is unfortunate; a lot of design mistakes could be avoided if this information were more widely known and deeply understood. (These mistakes are painfully common in home-grown PHP cryptography classes and functions, as many of the posts on Crypto Fails demonstrates.)
The concept itself is not difficult, but there is a rich supply of detail and nuance to be found beneath the surface.
Encryption is the process of rendering a message such that it becomes unreadable without possessing the correct key. In the simple case of symmetric cryptography, the same key is used for encryption as is used for decryption. In asymmetric cryptography, it is possible to encrypt a message with a user’s public key such that only possessing their private key can read it. Our white paper on PHP cryptography covers anonymous public-key encryption.
Authentication is the process of rendering a message tamper-resistant (typically within a certain very low probability, typically less than 1 divided by the number of particles in the known universe) while also proving it originated from the expected sender.
Note: When we say authenticity, we mean specifically message authenticity, not identity authenticity. That is a PKI and key management problem, which we may address in a future blog post.
In respect to the CIA triad: Encryption provides confidentiality. Authentication provides integrity.
Encryption does not provide integrity; a tampered message can (usually) still decrypt, but the result will usually be garbage. Encryption alone also does not inhibit malicious third parties from sending encrypted messages.
Authentication does not provide confidentiality; it is possible to provide tamper-resistance to a plaintext message.
A common mistake among programmers is to confuse the two. It is not uncommon to find a PHP library or framework that encrypts cookie data and then trusts it wholesale after merely decrypting it.
Message encryption without message authentication is a bad idea. Cryptography expert Moxie Marlinspike wrote about why message authentication matters (as well as the correct order of operations) in what he dubbed, The Cryptographic Doom Principle.
We previously defined encryption and specified that it provides confidentiality but not integrity or authenticity. You can tamper with an encrypted message and give the recipient garbage. But what if you could use this garbage-generating mechanism to bypass a security control? Consider the case of encrypted cookies.
The above code provides AES encryption in Cipher-Block-Chaining mode. If you pass a 32-byte string for $key, you can even claim to provide 256-bit AES encryption for your cookies and people might be misled into believing it’s secure.
Let’s say that, after logging into this application, you see that you receive a session cookie that looks like kHv9PAlStPZaZJHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==.
Let’s change a byte in the first block (the initialization vector) and iteratively sending our new cookie until something changes. It should take a total of 4096 HTTP requests to attempt all possible one-byte changes to the IV. In our example above, after 2405 requests, we get a string that looks like this: kHv9PAlStPZaZZHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==
For comparison, only one character differs in the base64-encoded cookie (kHv9PAlStPZaZJ vs kHv9PAlStPZaZZ):
The original data we stored in this cookie was an array that looked like this:
But after merely altering a single byte in the initialization vector, we were able to rewrite our message to read:
Depending on how the underlying app is set up, you might be able to flip one bit and become and administrator. Even though your cookies are encrypted.
If you would like to reproduce our results, our encryption key was 000102030405060708090a0b0c0d0e0f (convert from hexadecimal to raw binary).
As stated above, authentication aims to provide both integrity (by which we mean significant tamper-resistance) to a message, while proving that it came from the expected source (authenticity). The typical way this is done is to calculate a keyed-Hash Message Authentication Code (HMAC for short) for the message and concatenate it with the message.
It is important that an appropriate cryptographic tool such as HMAC is used here and not just a simple hash function.
These two functions are prefixed with unsafe because they are vulnerable to a number of flaws:
To authenticate a message, you always want some sort of keyed Message Authentication Code rather than just a hash with a key.
Using a hash without a key is even worse. While a hash function can provide simple message integrity, any attacker can calculate a simple checksum or non-keyed hash of their forged message. Well-designed MACs require the attacker to know the authentication key to forge a message.
Simple integrity without authenticity (e.g. a checksum or a simple unkeyed hash) is insufficient for providing secure communications.
In cryptography, if a message is not authenticated, it offers no integrity guarantees either. Message Authentication gives you Message Integrity for free.
The only surefire way to prevent bit-rewriting attacks is to make sure that, after encrypting your information, you authenticate the encrypted message. This detail is very important! Encrypt then authenticate. Verify before decryption.
Let’s revisit our encrypted cookie example, but make it a little safer. Let’s also switch to CTR mode, in accordance with industry recommended best practices. Note that the encryption key and authentication key are different.
Now we’re a little closer to our goal of robust symmetric authenticated encryption. There are still a few more questions left to answer, such as:
Fortunately, these questions are already answered in existing cryptography libraries. We highly recommend using an existing library instead of writing your own encryption features. For PHP developers, you should use defuse/php-encryption (or libsodium if it’s available for you). If you still believe you should write your own, consider using openssl, not mcrypt.
Note: There is a narrow band of use-cases where authenticated encryption is either impractical (e.g. software-driven full disk encryption) or unnecessary (i.e. the data is never sent over the network, even by folder synchronization services such as Dropbox). If you suspect your problems or goals permit unauthenticated ciphertext, consult a professional cryptographer, because this is not a typical use-case.
If you wish to implement encrypted cookies in one of your projects, check out Halite. It has a cookie class dedicated to this use case.
If you want to reinvent this wheel yourself, you can always do something like this:
For developers without access to libsodium (i.e. you aren’t allowed to install PHP extensions through PECL in production), one of our blog readers offered an example secure cookie implementation that uses defuse/php-encryption (the PHP library we recommend).
In our previous examples, we focused on building the encryption and authentication as separate components that must be used with care to avoid cryptographic doom. Specifically, we focused on AES in Cipher Block-Chaining mode (and more recently in Counter mode).
However, cryptographers have developed newer, more resilient modes of encryption that encrypt and authenticate a message in the same operation. These modes are called AEAD modes (Authenticated Encryption with Associated Data). Associated Data means whatever your application needs to authenticate, but not to encrypt.
AEAD modes are typically intended for stateful purposes, e.g. network communications where a nonce can be managed easily.
Two reliable implementations of AEAD are AES-GCM and ChaCha20-Poly1305.
In a few years, we anticipate the CAESAR competition will produce a next-generation authenticated encryption mode that we can recommend over these two.
And most importantly: Use a library with a proven record of resilience under the scrutiny of cryptography experts rather than hacking something together on your own. You’ll be much better off for it.
Read the original here:
Using Encryption and Authentication Correctly (for PHP …
What Is Encryption?
You may hear people use the term encryption and how you should use it to protect yourself and your information. However, encryption can be confusing and you should understand its limitations. In this newsletter, we explain in simple terms what encryption is, how it protects you, and how to implement it properly.
You have a tremendous amount of sensitive information on your devices, such as personal documents, pictures, and emails. If you were to have one of your devices lost or stolen, all of your sensitive information could be accessed by whoever possesses it. In addition, you may conduct sensitive transactions online, such as banking or shopping. If anyone were to monitor these activities, they could steal your information, such as your financial account or credit card numbers. Encryption protects you in these situations by helping ensure unauthorized people cannot access or modify your information.
Encryption has been around for thousands of years. Today, encryption is far more sophisticated, but it serves the same purpose — to pass a secret message from one place to another by ensuring only those authorized to read the message can access it. When information is not encrypted, it is called plain-text. This means anyone can easily read or access it. Encryption converts this information into a non-readable format called cipher-text. Todays encryption works by using complex mathematical operations and a unique key to convert your information into cipher-text. The key is what locks or unlocks your information. In most cases, your key is a password or passcode.
In general, there are two types of data to encrypt: data at rest (such as the data stored on your mobile device) and data in motion (such as retrieving email or messaging a friend).
Encrypting data at rest is vital to protect information in case your computer or mobile device is lost or stolen. Todays devices are extremely powerful and hold a tremendous amount of information, but are also very easy to lose. In addition, other types of mobile media can hold sensitive information, such as USB flash drives or external hard drives. Full Disk Encryption (FDE) is a widely used encryption technique that encrypts the entire drive in your system. This means that everything on the system is automatically encrypted for you; you do not have to decide what or what not to encrypt. Today, most computers come with FDE, but you may have to manually turn it on or enable it. It is called FileVault on Mac computers, while on Windows computers, depending on the version you have, you can use Bitlocker or Device Encryption. Most mobile devices also support FDE. iOS on iPhones and iPads automatically enable FDE once a passcode has been set. Starting with Android 6.0 (Marshmallow), Google is requiring FDE be enabled by default, provided the hardware meets certain minimum standards.
Information is also vulnerable when it is in transit. If the data is not encrypted, it can be monitored, modified, and captured online. This is why you want to ensure that any sensitive online transactions and communications are encrypted. A common type of online encryption is HTTPS. This means all traffic between your browser and a website is encrypted. Look for https:// in the URL, a lock icon on your browser, or your URL bar turning green. Another example is when you send or receive email. Most email clients provide encrypted capabilities, which you may have to enable. A third example of encrypting data in transit is between two users chatting with each other, such as with iMessage, Wickr, Signal, WhatsApp, or Telegram. Apps like these use end-to-end encryption, which prevents third parties from accessing data while its transferred from one end system or device to another. This means only you and the person youre communicating with can read what is sent.
To be sure you are protected when using encryption, it is paramount that you use it correctly:
OUCH! newsletter is under the Creative Commons license. You are free to share / distribute it but may not sell or modify it.
Continue reading here:
Encryption | SANS Security Awareness
Whole disk encryption, as the name implies, refers to the encryption of an entire physical or logical disk. While this is currently done mostly with software, hardware based disk encryption is a growing technology which is expected to surpass software products for whole disk encryption over the next few years. This form of encryption generally encrypts the entire contents of a disk or volume and decrypts/encrypts it during use after a key has been given. This means the data is protected from situations like laptop/disk loss or theft where the data would be encrypted and require a key to decrypt. It would not protect from situations like sending information over the network (e-mail, websites, etc) or from situations where the decryption key was already entered such as the user walking away from their logged-in computer.
When an individual wishes to encrypt a single file or group of files there are several options. Most encryption software has the ability to encrypt files individually using a password or other key. Many encryption programs have the ability to create an encrypted “virtual drive”. This is an encrypted file that, when opened with the key, looks like another drive attached to the computer allowing the user to easily open and save files into an encrypted area. Some other applications, like MS Office and OpenOffice, have built-in, single-file encryption features.
This approach can protect against data disclosure on a lost or stolen computer, but only if all of the private information was encrypted. Individual file/folder encryption relies on user education and good practices to ensure that all appropriate information is encrypted.
Depending on how the encryption software is used, this approach can provide protection from data disclosure when transferring information over the network. E.g. an individual file can be encrypted and then sent as an email attachment, assuming the recipient has the ability to decrypt it.
Allowing multiple users to simultaneously access encrypted information is more complicated than a single user. The encryption software must allow the use of either multiple keys (i.e. one for each user) or a shared key (e.g. a shared password). Additionally, the software must deal with multi-user file locking issues (this is usually a problem with the virtual drive approach mentioned in the last section).
This approach can provide an additional layer of protection against the disclosure of highly confidential data on file servers in the event they are compromised. It can also help protect against disclosure on backup media as the files would remain encrypted when backed up.
This approach can get complicated if not all users have the encryption software installed, or they are not configured consistently. This could lead users being unable to access encrypted information or incorrectly believing they have encrypted information when they have not. For these reasons, special attention should be paid to how encryption software behaves and users should be educated to recognize the encryption status of files.
Encrypting information in a database can be done at a couple of levels. The application accessing the database can encrypt information before putting it into the database. This requires intelligence at the application level, but no additional database features. Many databases have built-in encryption functions which applications can use to encrypt data as it is written. This usually requires features at both the application and database level. An encryption application can sit between the application and database, encrypting/decrypting information as it is written and read. This requires buying and installing additional software, but may not require modifications to the application or database.
As mentioned earlier, some applications that arent specifically designed for encryption do have basic encryption functions. Most notably, common productivity suites like Microsoft Office and OpenOffice contain file encryption features. Be cautious of the quality of the built-in encryption features, even within the Microsoft Office product line, some versions (like Office 2007) have a good mechanism, others have poor ones (like Office 2000 and earlier) and still others require proper configuration to provide good protection (like Office 2003). These features can be very handy because they dont require additional licenses, require less training and can be effective for both in transit and at rest encryption. Additionally, they can work well for file exchange since the recipient is more likely to have the ability to decrypt the file. In short, built-in encryption functions can be convenient options, but you should research their effectiveness before using them.
There are a couple of different levels to encryption with email, first is encrypting just an attached file and second is encrypting an entire message. Encrypting an attached file can be accomplished using any single-file encryption process that “sticks” to the file. Naturally, the recipient must have a way of decrypting the file. There are only a couple of commonly used email message encryption technologies, most notably S/MIME and PGP. While S/MIME support is integrated into many email clients, it requires users to have trusted certificates which can be complicated to properly deploy. Using PGP to encrypt email requires installing software, but there are both free and commercial options.
Both of these technologies also allow for digital “signing” of email without encrypting it. This signing process allows the recipient to be certain a message was not altered in transit, but does not protect the content from prying eyes.
Encrypting information while in transit on a network is one of the most common, and important, uses of encryption. One of the most popular forms of this encryption is Secure Sockets Layer (SSL)/Transport Layer Security (TLS), commonly used to encrypt web traffic in transit. Any web application that transmits or collects sensitive information should encrypt the information using SSL/TLS. There are a number of other uses for SSL/TLS encryption, including securing authentication for email communication between clients and servers. SSL/TLS can also be used for “tunneling” to encrypt other forms of network transmission that dont have their own encryption features.
Another common network encryption technology is Secure Shell (SSH) which is largely used for encrypted terminal connections (replacing telnet) and encrypted file transfers (SFTP replacing FTP). Like SSL/TLS, SSH can also be used for tunneling.
A more general form of network traffic encryption is IP Security (IPSec), which operates at a more basic layer than SSL or SSH and can be applied to any network traffic. However, using IPSec requires common configuration between the two computers communicating, so it is generally used within a company/department rather than across the internet.
For wireless networks there are other encryption options that only encrypt information between the computer and the wireless access point. For this reason, they only protect from snooping on wireless and not after the information leaves the access point onto a wired network. The two most common forms are called Wired Equivalent Privacy (WEP) and WiFI Protected Access (WPA). WEP is no longer considered a secure protocol. WPA is much stronger, but has shortcomings and an updated WPA2 standard has been released which improves its security.
Read more from the original source:
Types of Encryption | Office of Information Technology
Amazon S3 stores trillions of objects and processes more than a million requests per second for them.
As the number of use cases for S3 has grown, so have the requests for additional ways to protect data in motion (as it travels to and from S3) and at rest (while it is stored). The first requirement is met by the use of SSL, which has been supported by S3 from the very beginning. There are several options for the protection of data at rest. First, users of the AWS SDKs for Ruby and Java can also use client-side encryption to encrypt data before it leaves the client environment. Second, any S3 user can opt to use server-side encryption.
Today we are enhancing S3s support for server-side encryption by giving you the option to provide your own keys. You now have a choice you can use the existing server-side encryption model and let AWS manage your keys, or you can manage your own keys and benefit from all of the other advantages offered by server-side encryption.
You now have the option to store data in S3 using keys that you manage, without having to build, maintain, and scale your own client-side encryption fleet, as many of our customers have done in the past.
Use Your KeysThis new feature is accessible via the S3 APIs and is very easy to use. You simply supply your encryption key as part of a PUT and S3 will take care of the rest. It will use your key to apply AES-256 encryption to your data, compute a one-way hash (checksum) of the key, and then expeditiously remove the key from memory. It will return the checksum as part of the response, and will also store the checksum with the object. Heres the flow:
Later, when you need the object, you simply supply the same key as part of a GET. S3 will decrypt the object (after verifying that the stored checksum matches that of the supplied key) and return the decrypted object, once again taking care to expeditiously remove the key from memory.
Key ManagementIn between, it is up to you to manage your encryption keys and to make sure that you know which keys were used to encrypt each object. You can store your keys on-premises or you can use AWS Cloud HSM, which uses dedicated hardware to help you to meet corporate, contractual and regulatory compliance requirements for data security.
If you enable S3s versioning feature and store multiple versions of an object, you are responsible for tracking the relationship between objects, object versions, and keys so that you can supply the proper key when the time comes to decrypt a particular version of an object. Similarly, if you use S3s Lifecycle rules to arrange for an eventual transition to Glacier, you must first restore the object to S3 and then retrieve the object using the key that was used to encrypt it.
If you need to change the key associated with an object, you can invoke S3s COPY operation, passing in the old and the new keys as parameters. Youll want to mirror this change within your key management system, of course!
Ready to EncryptThis feature is available now and you can start using it today. There is no extra charge for encryption, and theres no observable effect on PUT or GET performance. To learn more, read the documentation on Server Side Encryption With Customer Keys.
View original post here:
Use Your own Encryption Keys with S3s Server-Side …
Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.
There are two primary approaches to encryption: symmetric key and asymmetric key encryption. In symmetric key encryption, one key is used to both encrypt and decrypt the information. Symmetric key encryption is analogous to the key used to both unlock and lock the door to a house. The big drawback of this approach is that if the key is compromised, it can be used to unlock, or decrypt, all of the data it was used to secure. For this reason, asymmetric key encryption was developed to allow multiple parties to exchange encrypted data without managing the same encryption key.
In asymmetric key encryption (also called public-key encryption), two different keys are used for the encryption and decryption processes. The public key can be freely distributed since it is only used to lock the data and never to unlock it. For example, a merchant can use a public key to encrypt payment data before sending a transaction to be authorized by a payment processing company. The latter company would need to have the private key to decrypt the card data to process the payment. Asymmetric key encryption is also used to validate identity on the Internet using SSL certificates.
Regardless of what type of key is utilized, users of encryption typically practice regular key rotation in order to reduce the likelihood of a compromised key being used to decrypt all sensitive data. Rotating keys limits the amount of data thats encrypted using a single key. In the event that an encryption key is compromised, only data encrypted with that key would be vulnerable.
Until now, one of the drawbacks of encrypting data within applications is that encryption breaks application functionality such as sorting and searching. Because cipher text is in a different format from the original data, encryption may also break field validation if an application requires specific formats within fields such as payment card numbers or email addresses. New order-preserving, format-preserving, and searchable encryption schemes are making it easier for organizations to protect their information without sacrificing end user functionality within business critical applications. However, there is usually a tradeoff between application functionality and the strength of encryption.
Tokenization is the process of turning a meaningful piece of data, such as an account number, into a random string of characters called a token that has no meaningful value if breached. Tokens serve as reference to the original data, but cannot be used to guess those values. Thats because, unlike encryption, tokenization does not use a mathematical process to transform the sensitive information into the token. There is no key, or algorithm, that can be used to derive the original data for a token. Instead, tokenization uses a database, called a token vault, which stores the relationship between the sensitive value and the token. The real data in the vault is then secured, often via encryption.
The token value can be used in various applications as a substitute for the real data. If the real data needs to be retrieved for example, in the case of processing a recurring credit card payment the token is submitted to the vault and the index is used to fetch the real value for use in the authorization process. To the end user, this operation is performed seamlessly by the browser or application nearly instantaneously. Theyre likely not even aware that the data is stored in the cloud in a different format.
The advantage of tokens is that there is no mathematical relationship to the real data they represent. If they are breached, they have no meaning. No key can reverse them back to the real data values. Consideration can also be given to the design of a token to make it more useful. For example, the last four digits of a payment card number can be preserved in the token so that the tokenized number (or a portion of it) can be printed on the customers receipt so she can see a reference to her actual credit card number. The printed characters might be all asterisks plus those last four digits. In this case, the merchant only has a token, not a real card number, for security purposes.
The most common use case for tokenization is protecting payment card data so that merchants can reduce their obligations under PCI DSS. Encryption can also be used to secure account data, but because the data is still present, albeit in ciphertext format, the organization must ensure the entire technology infrastructure used to store and transmit this data is fully compliant with PCI DSS requirements. In 2011, the Payment Card Industry Security Standards Council (PCI SSC), the organization responsible for enforcing PCI DSS, issued a set of tokenization guidelines. While the guidance has not yet been added to the official PCI DSS standard, qualified PCI assessors now accept tokenization as a viable solution to meet requirements under the standard.
Increasingly, tokens are being used to secure other types of sensitive or personally identifiable information, including social security numbers, telephone numbers, email addresses, account numbers and so on. The backend systems of many organizations rely on Social Security numbers, passport numbers, and drivers license numbers as unique identifiers. Since this unique identifier is woven into these systems, its very difficult to remove them. And these identifiers are also used to access information for billing, order status, and customer service. Tokenization is now being used to protect this data to maintain the functionality of backend systems without exposing PII to attackers.
While encryption can be used to secure structured fields such as those containing payment card data and PII, it can also used to secure unstructured data in the form of long textual passages, such as paragraphs or even entire documents. Encryption is also the ideal way to secure data exchanged with third parties and protect data and validate identity online, since the other party only needs a small encryption key. SSL or Secure Sockets Layer, the foundation of sharing data securely on the Internet today, relies on encryption to create a secure tunnel between the end user and the website. Asymmetric key encryption is also an important component of SSL certificates used to validate identity.
Encryption and tokenization are both regularly used today to protect data stored in cloud services or applications. Depending on the use case, an organization may use encryption, tokenization, or a combination of both to secure different types of data and meet different regularly requirements. McAfeeCASB, for example, leveragesan irreversible one-way process to tokenize user identifying information on premises and obfuscate enterprise identity.
As more data moves to the cloud, encryption and tokenization are being used to secure data stored in cloud services. Most notably, if a government agency subpoenas the data stored in the cloud, the service provider can only turn over encrypted or tokenized information with no way to unlock the real data. The same is true is a cyber criminal gains access to data stored in a cloud service.