Originally a banking trojan, Emotet later evolved into a full-blown botnet and went on to become one of the most dangerous cyberthreats worldwide
The post Emotet: sold or on vacation? – Week in security with Tony Anscombe appeared first on WeLiveSecurity
A brief summary of what happened with Emotet since its comeback in November 2021
The post What’s up with Emotet? appeared first on WeLiveSecurity
Criminals increasingly create deepfake nudes from people’s benign public photos in order to extort money from them, the FBI warns
The post Deepfaking it: What to know about deepfake‑driven sextortion schemes appeared first on WeLiveSecurity
Here are some of the key insights on the evolving data breach landscape as revealed by Verizon’s analysis of more than 16,000 incidents
The post Verizon 2023 DBIR: What’s new this year and top takeaways for SMBs appeared first on WeLiveSecurity
The growing use of synthetic media and difficulties in distinguishing between real and fake content raises a slew of legal and ethical questions
The post The good, the bad and the ugly of AI – Week in security with Tony Anscombe appeared first on WeLiveSecurity
In February, we expanded Google Workspace client-side encryption (CSE) capabilities to include Gmail and Calendar in addition to Drive, Docs, Slides, Sheets, and Meet.
CSE in Gmail was designed to provide commercial and public sector organizations an additional layer of confidentiality and data integrity protection beyond the existing encryption offered by default in Workspace. When CSE is enabled, email messages are protected using encryption keys that are fully under the customer’s control. The data is encrypted on the client device before it’s sent to Google servers that do not have access to the encryption keys, which means the data is indecipherable to us–we have no technical ability to access it. The entire process happens in the browser on the client device, without the need to install desktop applications or browser extensions, which means that users get the same intuitive productivity and collaboration experiences that they enjoy with Gmail today. Let’s take a deeper look into how it works.
How we built Client-side Encryption for Workspace
We invented and designed a new service called, Key Access Control List Service (KACLS), that is used across all essential Workspace applications. Then, we worked directly with customers and partners to make it secure, reliable, and simple to deploy. KACLS performs cryptographic operations with encryption keys after validating end-user authentication and authorization. It runs in a customer’s controlled environment and provides the key management API called by the CSE-enabled Workspace clients. We have multiple partners providing software implementations of the KACLS API that can be used by our customers.
At a high level, Workspace client code takes advantage of envelope encryption to encrypt and decrypt the user content on the client with a Data Encryption Key (DEK) and leverage the KACLS to encrypt and decrypt the DEK. In order to provide separation of duty, we use the customer’s OpenID Connect (OIDC) IdP to authenticate end-users and provide a JSON Web Token assertion with a claim identifying the user (3P_JWT). For every encryption/decryption request sent to KACLS, the application (e.g. Gmail) provides a JSON Web Token assertion with a claim authorizing the current end-user operation (G_JWT). KACLS validates these authentication and authorization tokens before returning, for example, a decrypted DEK to the user’s client device.
More details on KACLS are available in Google Workspace Encryption Whitepaper and CSE reference API.
How we built CSE into Gmail
Google Workspace Engineering teams have been hard at work over multiple years to deliver to our customers the ability to have their data protected with client-side encryption. This journey required us to work closely with customers and partners to provide a capability that was secure, easy to use, intuitive and easily deployable. It was also important for CSE to work seamlessly across the Workspace products: you can create a Meet CSE scheduled meeting in Calendar CSE and follow-up with Gmail CSE emails containing links to Drive CSE files.
Client-side encryption in Gmail was built with openness and interoperability in mind. The underlying technology being used is S/MIME, an open standard for sending encrypted messages over email. S/MIME is already supported in most enterprise email clients, so users are able to communicate securely, outside of their domain, regardless of what provider the recipient is using to read their mail, without forcing the recipients to log into a proprietary portal. S/MIME uses asymmetric encryption. The public key and the email of each user are included in the user’s S/MIME certificate. Similarly to TLS used for HTTPS, each certificate is digitally signed by a chain of certificate authorities up to a broadly trusted root certificate authority. The certificate acts as a virtual business card, enabling anyone getting it to encrypt emails for that user. The user’s private keys are kept secure under customer control and are used by users for decryption of incoming emails and digital signature of outgoing emails.
We decided to leverage the CSE paradigm used for Drive CSE and not keep the private key on the device, to keep them as safe as possible. Instead, we extended our KACLS API to support asymmetric encryption and signature operations. This enables our customers to centrally provision and enable S/MIME, on the KACLS, for all their users without having to deploy certificates individually to each user device.
CSE in Gmail uses the end-user’s client existing cryptographic functionalities (Web Crypto API for web browsers for instance) to perform local encryption operations and run client-side code to perform all S/MIME message generation.
Now let’s cover the detailed user flows:
When sending an email, the Gmail client generates a MIME message, encrypts the message with a random Data Encryption Key (DEK) then uses the recipients’ public keys to encrypt the DEK, calls KACLS (with the user authenticated by customer’s IdP and authorized by Google) to digitally sign content and finally sends the authenticated and encrypted S/MIME message, which contains both the encrypted email and the encrypted DEK, to Google servers for delivery to the recipients.
When receiving an email, Gmail will verify that the digital signature of the email is valid and matches the sender’s identity, which protects the email against tampering. Gmail will trust digital identities signed by Root CA PKI as well as custom domain configurations. The Gmail client will call KACLS (with the authentication and authorization JWT) to decrypt the email encryption key, then can decrypt the email and render it to the end-user.
How we protect the application
Workspace already uses the latest cryptographic standards to encrypt all data at rest and in transit between its facilities for all services. Additionally, Gmail uses Transport Layer Security (TLS) by default for communication with other email service providers. CSE in Gmail, however, provides an additional layer of protection for sensitive content. The security of Gmail CSE is paramount to us, and we developed new additional mechanisms to ensure CSE content would be locked into a secure container. On the web, we have been leveraging iframe origin isolation, strict postMessage API, and Content Security Policy to protect the user’s sensitive data. Those security controls provide multiple layers of safety to ensure that CSE content stays isolated from the rest of the application. See this simplified diagram covering the isolation protecting CSE emails during composition or display.
What’s next for Client-side encryption and why it’s important
CSE in Gmail uses S/MIME to encrypt and digitally sign emails using public keys supplied by customers, which add an additional level of confidentiality and integrity to emails. This is done with extensive security controls to protect user data confidentiality, but also transparently integrated in Gmail UI to delight our users. However our work is not done, and we are actively partnering with Google Research to further develop client-side capabilities. You can see some of our progress in this field with our presentation at the RSA Security Conference last year where we provided insight into the challenges and the practical strategies to provide advanced capabilities, such as AI-driven phishing protection for CSE.
While employee monitoring software may boost productivity, it may also be a potential privacy minefield and it can affect your relationship with your employees
The post Employee monitoring: is ‘bossware’ right for your company? appeared first on WeLiveSecurity
Cybercriminals can use USB charging stations in airports, hotels, malls or other public spaces as conduits for malware
The post Avoid juice jacking and recharge your batteries safely this summer appeared first on WeLiveSecurity
The beginning of the summer break is the perfect time for parents to remind their children about the importance of safe online habits
The post School’s out for summer, but it’s not time to let your cyber guard down appeared first on WeLiveSecurity
“Secure your dependencies”—it’s the new supply chain mantra. With attacks targeting software supply chains sharply rising, open source developers need to monitor and judge the risks of the projects they rely on. Our previous installment of the Supply chain security for Go series shared the ecosystem tools available to Go developers to manage their dependencies and vulnerabilities. This second installment describes the ways that Go helps you trust the integrity of a Go package.
Go has built-in protections against three major ways packages can be compromised before reaching you:
A new, malicious version of your dependency is published
A package is withdrawn from the ecosystem
A malicious file is substituted for a currently used version of your dependency
In this blog post we look at real-world scenarios of each situation and show how Go helps protect you from similar attacks.
In 2018, control of the JavaScript package event-stream passed from the original maintainer to a project contributor. The new owner purposefully published version 3.3.6 with a new dependency named flatmap-stream, which was found to be maliciously executing code to steal cryptocurrency. In the two months that the compromised version was available, it had been downloaded 8 million times. This poses the question – how many users were unaware that they had adopted a new indirect dependency?
Go ensures reproducible builds thanks to automatically fixing dependencies to a specific version (“pinning”). A newly released dependency version will not affect a Go build until the package author explicitly chooses to upgrade. This means that all updates to the dependency tree must pass code review. In a situation like the event-stream attack, developers would have the opportunity to investigate their new indirect dependency.
In 2016, an open-source developer pulled his projects from npm after a disagreement with npm and patent lawyers over the name of one of his open-source libraries. One of these pulled projects, left-pad, seemed to be small, but was used indirectly by some of the largest projects in the npm ecosystem. Left-pad had 2.5 million downloads in the month before it was withdrawn, and its disappearance left developers around the world scrambling to diagnose and fix broken builds. Within a few hours, npm took the unprecedented action to restore the package. The event was a wake up call to the community about what can happen when packages go missing.
Go guarantees the availability of packages.The Go Module Mirror serves packages requested by the go command, rather than going to the origin servers (such as GitHub). The first time any Go developer requests a given module, it’s fetched from upstream sources and cached within the module mirror. When a module has been made available under a standard open source license, all future requests for that module simply return the cached copy, even if the module is deleted upstream.
In December 2022, users who installed the package pyTorch-nightly via pip, downloaded something they didn’t expect: a package that included all the functionality of the original version but also ran a malicious binary that could gain access to environment variables, host names, and login information.
This compromise was possible because pyTorch-nightly had a dependency named torchtriton that shipped from the pyTorch-nightly package index instead of PyPI. An attacker claimed the unused torchtriton namespace on PyPI and uploaded a malicious package. Since pip checks PyPI first when performing an install, the attacker got their package out in front of the real package—a dependency confusion attack.
Go protects against these kinds of attacks in two ways. First, it is harder to hijack a namespace on the module mirror because publicly available projects are added to it automatically—there are no unclaimed namespaces of currently available projects. Second, package authenticity is automatically verified by Go’s checksum database.
The checksum database is a global list of the SHA-256 hashes of source code for all publicly available Go modules. When fetching a module, the go command verifies the hashes against the checksum database, ensuring that all users in the ecosystem see the same source code for a given module version. In the case of pyTorch-nightly, a checksum database would have detected that the torchtriton version on PyPI did not match the one served earlier from pyTorch-nightly.
How do we know that the values in the Go checksum database are trustworthy? The Go checksum database is built on a Transparent Log of hashes of every Go module. The transparent log is backed by Trillian, a production-quality, open-source implementation also used for Certificate Transparency. Transparent logs are tamper-evident by design and append-only, meaning that it’s impossible to delete or modify Go module hashes in the logs without the change being detected.
The Go team supports the checksum database and module mirror as services so that Go developers don’t need to worry about disappearing or hijacked packages. The future of supply chain security is ecosystem integration, and with these services built directly into Go, you can develop with confidence, knowing your dependencies will be available and uncorrupted.
The final part of this series will discuss the Go tools that take a “shift left” approach to security—moving security earlier in the development life cycle. For a sneak peek, check out our recent supply chain security talk from Google I/O!
