Search the Community

AWS Transfer Family now provides you with the option to import and use a trading partner’s public, self-signed TLS certificate for sending Applicability Statement 2 (AS2) messages to their server over HTTPS. Additionally, you can now choose to encrypt messages sent to your partner’s server using the 3DES cipher. By default, AS2 connectors will encrypt messages with the AES128 cipher unless you select 3DES for purposes of backwards compatibility with your partner’s existing AS2 implementation. These capabilities add to AWS Transfer Family’s existing list of AS2 interoperability features and enable you to reliably connect with trading partners that require these specific security configurations. View the full article

When the impact of a relatively unfamiliar technology sounds too good to be true, it’s natural to question those claims. Homomorphic encryption has been described as the ‘holy grail’ of encryption for its unique ability to allow users to leverage […] The post From Promising to Practical: The Transformative Impact of Homomorphic Encryption appeared first on TechSpective. The post From Promising to Practical: The Transformative Impact of Homomorphic Encryption appeared first on Security Boulevard. View the full article

Researchers have discovered a new side-channel vulnerability in Apple’s M-series of processors that they claim could be used to extract secret keys from Mac devices when they’re performing cryptographic operations. Academic researchers from the University of Illinois Urbana-Champaign, University of Texas at Austin, Georgia Institute of Technology, University of California, University of Washington, and Carnegie Mellon University, explained in a research paper that the vulnerability, dubbed GoFetch, was found in the chips’ data memory-dependent prefetcher (DPM), a optimization mechanism that predicts the memory addresses of data that active code could access in the near future. Since the data is loaded in advance, the chip makes performance gains. However, as the prefetchers make predictions based on previous access patterns, they also create changes in state that the attackers can observe, and then use to leak sensitive information. GoFetch risk The vulnerability is not unlike the one abused in Spectre/Meltdown attacks as those, too, observed the data the chips loaded in advance, in order to improve the performance of the silicon. The researchers also noted that this vulnerability is basically unpatchable, since it’s derived from the design of the M chips themselves. Instead of a patch, the only thing developers can do is build defenses into third-party cryptographic software. The caveat with this approach is that it could severely hinder the processors’ performance for cryptographic operations. Apple has so far declined to discuss the researchers’ findings, and stressed that any performance hits would only be visible during cryptographic operations. While the vulnerability itself might not affect the regular Joe, a future patch hurting the device’s performance just might. Those interested in reading about GoFetch in depth, should check out the research paper here. Via Ars Technica More from TechRadar Pro This nasty new Android malware can easily bypass Google Play security — and it's already been downloaded thousands of timesHere's a list of the best firewalls around todayThese are the best endpoint security tools right now View the full article

The post Duplicity – Create Encrypted Incremental Backups in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides .Experience shows that you can never be too paranoid about system backups. When it comes to protecting and preserving precious data, it is best to The post Duplicity – Create Encrypted Incremental Backups in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides.View the full article

OpenTDF lets you integrate encryption and data policy controls into your new and existing apps to safeguard your data. View the full article

Amazon CloudWatch Logs now supports exporting logs to Amazon Simple Storage Service (S3) buckets encrypted using Server side encryption with KMS (SSE-KMS) keys. View the full article

Encryption and data protection is a major requirement for customers moving their workloads to the cloud. To meet this requirement, organizations often invest a great deal of time in protecting sensitive data in cloud-based databases. This is driven mostly by government regulations, compliance, and organizations’ security requirements to have data protected at rest. As Customer Engineers on the Security and Compliance technology team in Google Cloud, we engage both executive and technical stakeholders to help customers build secure deployments that enable their digital transformation on our Cloud platform. As Google Cloud continues its efforts to be the industry’s most trusted cloud, we’re taking steps to help customers better understand encryption options available to protect workloads on our platform. In this post, we provide a guide on how to accelerate your design considerations and decision making when securely migrating or building databases with the various encryption options supported on Google Cloud platform. Managing data at rest with encryption on Google Cloud When you move data to Google Cloud, you have options to choose from databases that are simple to use and operate without cumbersome maintenance tasks and operational overhead. Google Cloud keeps the databases highly available and updated, while your IT team can focus on delivering innovations and your end users enjoy reliable services. Additionally, you inherit security controls like encryption of data at-rest by default that can help simplify your security implementations. For most organizations, encryption is one piece of a broader security strategy. Encryption adds a layer of defense in depth for protecting data and provides an important mechanism for how Google helps ensure the privacy of data. Encryption ensures that if the data accidentally falls into an attacker's hands, they cannot access the data without also having access to the encryption keys. Our platform offers data-at-rest encryption by default, ensuring that all data stored within the cloud is encrypted by Google-managed keys. Management options for encryption keys Google Managed Keys: All data stored within Google Cloud is encrypted at rest using the same hardened key management systems that we use for our own encrypted data. These key-management systems provide strict access controls and auditing, and encrypt user data at rest using AES-256 encryption standards. No setup, configuration, or management is required. Google managed keys is an appropriate choice if you don't have specific requirements related to compliance or locality of cryptographic materials. Customer Managed Keys: Customer managed encryption keys (CMEK) offer the ability to protect your databases with encryption keys you control and manage. Using CMEK gives you control over more aspects of the lifecycle and management of your keys, such as key rotation, defining access control policies, auditing and logging, and enforcing data locality or residency requirements. CMEKs are supported on Cloud Key Management Service, Cloud Hardware Security Module, and Cloud External Key Manager. Encryption options for Google Cloud databases In addition to default security controls inherited on Google Cloud, we believe customers should have options to choose the level of protection over data stored in the cloud. We’ve developed database products integrated with our encryption capabilities that enable you to control your data and provide expanded granularity into when and how data is accessed. Google’s default encryption: Customers' content stored on our platform is encrypted at rest, without any action from customers using multiple encryption mechanisms. Data for storage is split into chunks, and each chunk is encrypted with a unique data encryption key. The data encrypted keys are protected with key encryption keys (KEK) and stored centrally in Google's KMS, a repository built specifically for storing keys. Cloud Key Management Service (Cloud KMS) provides you with the capability to manage cryptographic keys in a central cloud service for either direct use or use by other cloud resources such as databases and datastores. Cloud KMS combines secure, highly available infrastructure with capabilities not only to provide the mechanisms to create keys of various types and strengths, but also an option for the keys to remain exclusively within the Google Cloud region with which the data is associated. Cloud Hardware Security Module (Cloud HSM) enables you to generate encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 certified HSMs. The service is fully managed, so you can protect your most sensitive workloads without worrying about the operational overhead of managing an HSM cluster. Google manages the HSM hardware, automatically scales based on your use, spares you the complexity of managing and using HSM-backed keys in production. For example, you can encrypt data in Cloud SQL tables using a Cloud HSM key that you manage and control the life cycle of. Cloud External Key Manager (EKM) gives you ultimate control over the keys and encrypted data-at-rest within Google Cloud resources such as CloudSQL, Cloud Spanner, etc. Google EKM enables you to use keys managed in a supported key management system external to Google to protect data within Google Cloud. It’s important to note that for this option, externally managed keys are never cached or stored within Google Cloud. Whenever Google Cloud needs to decrypt data, it communicates directly with the external key manager. In addition to Cloud EKM, customers may leverageKey Access Justifications to understand why their externally-hosted keys are being requested to decrypt data. Here’s a look at the encryption options for database services that Google Cloud offers Database Platform Google Cloud Database service Encryption Options Supported Microsoft SQL Server Cloud SQL for SQL Server Google default encryption Cloud KMS CloudHSM CloudEKM MySQL Cloud SQL for MySQL Google default encryption Cloud KMS CloudHSM CloudEKM PostgreSQL Cloud SQL for PostgreSQL Google default encryption Cloud KMS CloudHSM CloudEKM MongoDB MongoDB Atlas Google default encryption Cloud KMS CloudHSM Apache HBase Cloud BigTable Google default encryption Cloud KMS CloudHSM CloudEKM PostgreSQL CloudSpanner for PostgreSQL Google default encryption Cloud KMS CloudHSM CloudEKM Google Standard SQL CloudSpanner Google Standard SQL Google default encryption Cloud KMS CloudHSM CloudEKM Redis Memory Store Memorystore for Redis. Google default encryption Cloud KMS CloudHSM Firestore Firestore Google default encryption Oracle Database Bare Metal Solution for Oracle Customer owned key management system For more information on Key Management on GCP read our KMS Deep Dive Whitepaper.

We’re excited to announce the support for encryption at rest for datasets and machine learning (ML) models on Amazon SageMaker Canvas using customer managed keys with AWS Key Management Service (KMS). Amazon SageMaker Canvas is a visual point-and-click interface that enables business analysts to generate accurate ML predictions on their own — without requiring any machine learning experience or having to write a single line of code. SageMaker Canvas makes it easy to access and combine data from a variety of sources, automatically clean data, and build ML models to generate accurate predictions with a few clicks. View the full article

Field level encryption (FLE) allows developers to selectively encrypt specific data fields. It helps protect sensitive data and enhances the security of communication between client apps and server. Pairing an FTE-capable database with a KMIP provider offers the highest level of security and control. The Key Management Interoperability Protocol (KMIP) standard is a widely adopted approach to handle cryptographic workloads and secrets management for enterprise infrastructure such as databases, network storage, and virtual and physical servers. HashiCorp Vault, being a KMIP compliant Key Management Server (KMS), enables organizations to perform cryptographic operations for their apps and services. With MongoDB releasing client-side field level encryption with KMIP support, customers are now able to use Vault’s KMIP secrets engine to supply the encryption keys. This allows customers to be in full control of their keys... View the full article

Amazon Relational Database Service (Amazon RDS) can now publish events to Amazon Simple Notification Service (Amazon SNS) topics that have server-side encryption (SSE) enabled, for additional protection of events that carry sensitive data. Amazon RDS groups events into categories that you can subscribe to so that you can be notified when an event in that category occurs, enabling routing and automation. View the full article

Amazon ElastiCache for Memcached now supports encryption of data in transit using Transport Layer Security (TLS) version 1.2. When using encryption in transit, all network traffic between your clients and Memcached cluster are encrypted. View the full article

The post How to Encrypt Full Disk While Installing Ubuntu 22.04 first appeared on Tecmint: Linux Howtos, Tutorials & Guides .Linux distributions have done a great job to get additional protection by bringing full disk encryption and being the market leader. Ubuntu also is bundled with numerous features and disk encryption is one of The post How to Encrypt Full Disk While Installing Ubuntu 22.04 first appeared on Tecmint: Linux Howtos, Tutorials & Guides.View the full article

Developers can now use the AWS Encryption SDK for .NET to help protect their data. This open-source release makes it easier for developers to encrypt and decrypt their data when building applications using the .NET developer platform. View the full article

AWS IoT SiteWise is a managed service that makes it easy to collect, store, organize and monitor data from industrial equipment at scale to help you make better, data-driven decisions. View the full article

Amazon SageMaker Studio is the first fully integrated development environment (IDE) for machine learning (ML). It provides a single, web-based visual interface where you can perform all ML development steps required to build, train, tune, debug, deploy, and monitor models. Starting today, you can encrypt your Amazon SageMaker Studio storage volumes with customer master keys (CMKs) managed by you in AWS Key Management Service (KMS). View the full article

With Amazon DynamoDB global tables, you can give massively scaled, global applications local access to DynamoDB tables for fast read and write performance. All of your data in DynamoDB is encrypted by default using the AWS Key Management Service (KMS). Starting today, you can now choose a customer managed key for your global tables, giving you full control over the key used for encryption of your DynamoDB data replicated using global tables. Customer managed keys also come with full AWS CloudTrail monitoring so you can view every time the key was used or accessed. View the full article

Cloud Spanner is Google Cloud’s fully managed relational database that offers unlimited scale, high performance, strong consistency across regions and high availability (up to 99.999% availability SLA). In addition, enterprises trust Spanner because it provides security, transparency and complete data protection to its customers. To give enterprises greater control of how their data is secured, Spanner recently launched Customer-managed encryption keys (CMEK). CMEK enables customers to manage encryption keys in Cloud Key Management (KMS). From a security standpoint, Spanner already offers, by default, encryption for data-in-transit via its client libraries and for data at rest using Google-managed encryption keys. Customers in regulated industries such as financial services, healthcare and life sciences, and telecommunications need control of the encryption keys to meet their compliance requirements. With the launch of CMEK support for Spanner, you now have complete control of the encryption keys and can run workloads that require the highest level of security and compliance. You can also protect database backups with CMEK. Spanner also provides VPC Service Controls support and has compliance certifications and necessary approvals so that it can be used for workloads requiring ISO 27001, 27017, 27018, PCI DSS, SOC1|2|3, HIPAA and FedRamp. Spanner integrates with Cloud KMS to offer CMEK support, enabling you to generate, use, rotate, and destroy cryptographic keys in Cloud KMS. Customers who need an increased level of security can choose to use hardware-protected encryption keys, and can host encryption keys and perform cryptographic operations in FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs). CMEK capability in Spanner is available in all Spanner regions and select multi-regions that support KMS and HSM. How to use CMEK with Spanner To use CMEK for a Spanner database, users should specify the KMS key at the time of database creation. The key must be in the same location as the Spanner instance (regional or multi-regional). Spanner is able to access the key on user’s behalf after the user grants the Cloud KMS Encrypter and Decrypter role to a Google-managed Cloud Spanner service account. Once a database with CMEK is created, the access to it via APIs, DDL and DML is the same as for a database using Google-managed encryption keys. You can see the details of the encryption type and encryption key in the database overview page. Spanner calls KMS in each zone of an instance-configuration about every five minutes to ensure that the key for the Spanner database is still valid. Customers can audit the Spanner requests to KMS on their behalf in the Logs Viewer if they enable logging for Cloud KMS API in their project. Access approval support for Spanner In addition to security controls, customers need complete visibility and control over how their data is used. Customers today use Cloud Spanner audit logs to record the admin and data access activities for members in their Google Cloud organization, whereas they enable Access Transparency logs to record the actions taken by Google personnel. Access Transparency provides near real-time logs to customers where Google support and engineering personnel logs business justification (including reference to support tickets in some scenarios) for any access to customer’s data. Expanding on this, Spanner has launched support for Access Approval in Preview. With Access Approval in Spanner, a customer blocks administrative access to their data from Google personnel and requires explicit approval from them to proceed. Hence, this is an additional layer of control on top of the transparency provided by Access Transparency Logs. Access Approval also provides a historical view of all requests that were approved, dismissed, or expired. To use Access Approval, customers have to first enable Access Transparency from the console for their organization; Access Approval can then be enabled from the console as well. With Access Approval, users will receive an email or Pub/Sub message with an access request that they are able to approve. Using the information in the message, they can use the Google Cloud Console or the Access Approval API to approve the access. Learn more Spanner bills a CMEK-enabled database the same as any other Spanner database. Customers are billed for Cloud KMS use (for the cost of the key and for cryptographic operations) whenever Spanner uses the key for encryption/decryption. We expect this cost to be minimal; see KMS pricing for details. To learn more about CMEK, see documentation. To get started with Spanner, create an instanceor try it out with a Spanner Qwiklab. Related Article Cloud Spanner launches point-in-time-recovery capability Check out Cloud Spanner’s new point-in-time recovery (PITR) capability, offering continuous data protection when you configure the databa... Read Article

The Btrfs filesystem-level encryption feature is still not available. But you can use a 3rd party encryption tool like dm-crypt to encrypt the entire storage devices of your Btrfs filesystem. In this article, I am going to show you how to encrypt the storage devices added to a Btrfs filesystem with dm-crypt. So, let’s get started. Abbreviations LUKS – Linux Unified Key Setup HDD – Hard Disk Drive SSD – Solid-State Drive Prerequisites To follow this article: You must be running either Fedora 33 Workstation or Ubuntu 20.04 LTS Linux distribution on your computer. You must have a free HDD/SSD on your computer. As you can see, I have an HDD sdb on my Ubuntu 20.04 LTS machine. I will encrypt it and format it with the Btrfs filesystem. $ sudo lsblk -e7 Installing Required Packages on Ubuntu 20.04 LTS To encrypt storage devices and format them with the Btrfs filesystem, you need to have the btrfs-progs and cryptsetup packages installed on your Ubuntu 20.04 LTS machine. Luckily, these packages are available in the official package repository of Ubuntu 20.04 LTS. First, update the APT package repository cache with the following command: $ sudo apt update To install btrfs-progs and cryptsetup, run the following command: $ sudo apt install btrfs-progs cryptsetup --install-suggests To confirm the installation, press Y and then press <Enter>. The btrfs-progs and cryptsetup packages and their dependencies are being installed. The btrfs-progs and cryptsetup packages should be installed at this point. Installing Required Packages on Fedora 33 To encrypt storage devices and format them with the Btrfs filesystem, you need to have the btrfs-progs and cryptsetup packages installed on your Fedora 33 Workstation machine. Luckily, these packages are available in the official package repository of Fedora 33 Workstation. First, update the DNF package repository cache with the following command: $ sudo dnf makecache To install btrfs-progs and cryptsetup, run the following command: $ sudo dnf install btrfs-progs cryptsetup -y Fedora 33 Workstation uses the Btrfs filesystem by default. So, it’s more likely that you will have these packages installed already, as you can see in the screenshot below. If for some reason, they are not installed, they will be installed. Generating an Encryption Key Before you can encrypt your storage devices with cryptsetup, you need to generate a 64 bytes long random key. You can generate your encryption key and store it in the /etc/cryptkey file with the following command: $ sudo dd if=/dev/urandom of=/etc/cryptkey bs=64 count=1 A new encryption key should be generated and stored in the /etc/cryptkey file. The encryption key file /etc/cryptkey can be read by everyone by default, as you can see in the screenshot below. This is a security risk. We want only the root user to be able to read/write to the /etc/cryptkey file. $ ls -lh /etc/cryptkey To allow only the root user to read/write to the /etc/cryptkey file, change the file permissions as follows: $ sudo chmod -v 600 /etc/cryptkey As you can see, only the root user has read/write (rw) permission to the /etc/cryptkey file. So, no one else can see what’s in the /etc/cryptkey file. $ ls -lh /etc/cryptkey Encrypting the Storage Devices with dm-crypt Now that you have generated an encryption key, you can encrypt your storage device. let’s say, sdb, with the LUKS v2 (version 2) disk encryption technology as follows: $ sudo cryptsetup -v --type luks2 luksFormat /dev/sdb /etc/cryptkey cryptsetup will prompt you to confirm the encryption operation. NOTE: All the data of your HDD/SSD should be removed. So, make sure to move all of your important data before you attempt to encrypt your HDD/SSD. To confirm the disk encryption operation, type in YES (in uppercase) and press <Enter>. It may take a while to complete. At this point, the storage device /dev/sdb should be encrypted with the encryption key /etc/cryptkey. Opening Encrypted Storage Devices Once you’ve encrypted a storage device with cryptsetup, you need to open it with the cryptsetup tool to be able to use it. You can open the encrypted storage device sdb and map it to your computer as a data storage device as follows: $ sudo cryptsetup open --key-file=/etc/cryptkey --type luks2 /dev/sdb data Now, the decrypted storage device will be available in the path /dev/mapper/data. You have to create your desired filesystem in the /dev/mapper/data device and mount the /dev/mapper/data device instead of /dev/sdb from now on. Creating Btrfs Filesystem on Encrypted Devices: To create a Btrfs filesystem on the decrypted storage device /dev/mapper/data with the label data, run the following command: $ sudo mkfs.btrfs -L data /dev/mapper/data A Btrfs filesystem should be created on the /dev/mapper/data storage device, which is decrypted from the storage device /dev/sdb (encrypted with LUKS 2). Mounting Encrypted Btrfs Filesystem You can mount the Btrfs filesystem you have created earlier as well. Let’s say, you want to mount the Btrfs filesystem you’ve created earlier in the /data directory. So, create the /data directory as follows: $ sudo mkdir -v /data To mount the Btrfs filesystem created on the /dev/mapper/data storage device in the /data directory, run the following command: $ sudo mount /dev/mapper/data /data As you can see, the Btrfs filesystem created on the encrypted storage device sdb is mounted in the /data directory. $ sudo btrfs filesystem show /data Automatically Mounting Encrypted Btrfs Filesystem at Boot-Time You can mount the encrypted Btrfs filesystem at boot time as well. To mount the encrypted Btrfs filesystem at boot time, you need to: decrypt the storage device /dev/sdb at boot time using the /etc/cryptkey encryption key file mount the decrypted storage device /dev/mapper/data to the /data directory First, find the UUID of the sdb encrypted storage device with the following command: $ sudo blkid /dev/sdb As you can see, the UUID of the sdb encrypted storage device is 1c66b0de-b2a3-4d28-81c5-81950434f972. It will be different for you. So, make sure to change it with yours from now on. To automatically decrypt the sdb storage device at boot time, you have to add an entry for it on the /etc/crypttab file. Open the /etc/crypttab file with the nano text editor as follows: $ sudo nano /etc/crypttab Add the following line at the end of the /etc/crypttab file if you’re using an HDD. data UUID=1c66b0de-b2a3-4d28-81c5-81950434f972 /etc/cryptkey luks,noearly Add the following line at the end of the /etc/crypttab file if you’re using an SSD. data UUID=1c66b0de-b2a3-4d28-81c5-81950434f972 /etc/cryptkey luks,noearly,discard Once you’re done, press <Ctrl> + X, followed by Y, and <Enter> to save the /etc/crypttab file. Now, find the UUID of the decrypted /dev/mapper/data storage device with the following command: $ sudo blkid /dev/mapper/data As you can see, the UUID of the /dev/mapper/data decrypted storage device is dafd9d61-bdc9-446a-8b0c-aa209bfab98d. It will be different for you. So, make sure to change it with yours from now on. To automatically mount the decrypted storage device /dev/mapper/data in the /data directory at boot time, you have to add an entry for it on the /etc/fstab file. Open the /etc/fstab file with the nano text editor as follows: $ sudo nano /etc/fstab Now, add the following line at the end of the /etc/fstab file: UUID=dafd9d61-bdc9-446a-8b0c-aa209bfab98d /data btrfs defaults 0 0 Once you’re done, press <Ctrl> + X, followed by Y, and <Enter> to save the /etc/fstab file. Finally, reboot your computer for the changes to take effect. $ sudo reboot The encrypted storage device sdb is decrypted into a data storage device, and the data storage device is mounted in the /data directory. $ sudo lsblk -e7 As you can see, the Btrfs filesystem, which was created on the decrypted /dev/mapper/data storage device is mounted in the /data directory. $ sudo btrfs filesystem show /data Conclusion In this article, I have shown you how to encrypt a storage device using the LUKS 2 encryption technology with cryptsetup. You also learn how to decrypt the encrypted storage device and format it with the Btrfs filesystem as well. As well as how to automatically decrypt the encrypted storage device and mount it at boot time. This article should help you get started with Btrfs filesystem encryption. View the full article