All posts by Oleg Afonin

Elcomsoft iOS Forensic Toolkit can perform full file system acquisition and decrypt the keychain from non-jailbroken iPhone and iPad devices. The caveat: the device must be running iOS 11 or 12 (except iOS 12.3, 12.3.1 and 12.4.1), and you must use an Apple ID registered in Apple’s Developer Program. In this article, I’ll explain the pros and contras of the new extraction method compared to traditional acquisition based on the jailbreak.

Why jailbreak?

Before I start talking about the new extraction method that does not require a jailbreak, let me cover the jailbreak first. In many cases, jailbreaking the device is the only way to obtain the file system and decrypt the keychain from iOS devices. Jailbreaking the device provides the required low-level access to the files and security keys inside the device, which is what we need to perform the extraction.

Jailbreaks have their negative points; lots of them in fact. Jailbreaking may be dangerous if not done properly. Jailbreaking the device can modify the file system (especially if you don’t pay close attention during the installation). A jailbreak installs lots of unnecessary stuff, which will be difficult to remove once you are done with extraction. Finally, jailbreaks are obtained from third-party sources; obtaining a jailbreak from the wrong source may expose the device to malware. For these and other reasons, jailbreaking may not be an option for some experts.

This is exactly what the new acquisition method is designed to overcome.

Agent-based extraction

The new extraction method is based on direct access to the file system, and does not require jailbreaking the device. Using agent-based extraction, you can can perform the full file system extraction and decrypt the keychain without the risks and footprint associated with third-party jailbreaks.

Agent-based extraction is new. In previous versions, iOS Forensic Toolkit offered the choice of advanced logical extraction (all devices) and full file system extraction with keychain decryption (jailbroken devices only). The second acquisition method required installing a jailbreak.

EIFT 5.30 introduced the third extraction method based on direct access to the file system. The new acquisition method utilizes an extraction agent we developed in-house. Once installed, the agent will talk to your computer, delivering significantly better speed and reliability compared to jailbreak-based extraction. In addition, agent-based extraction is completely safe as it neither modifies the system partition nor remounts the file system while performing automatic on-the-fly hashing of information being extracted. Agent-based extraction does not make any changes to user data, offering forensically sound extraction. Both the file system image and all keychain records are extracted and decrypted. Once you are done, you can remove the agent with a single command.

Compatibility of agent-based extraction

Jailbreak-free extraction is only available for a limited range of iOS devices. Supported devices range from the iPhone 5s all the way up to the iPhone Xr, Xs and Xs Max if they run any version of iOS from iOS 11 through iOS 12.4 (except iOS 12.3 and 12.3.1). Apple iPad devices running on the corresponding SoC are also supported. Here’s where agent-based extraction stands compared to other acquisition methods:

 

The differences between the four acquisition methods are as follows.

  1. Logical acquisition: works on all devices and versions of iOS and. Extracts backups, a few logs, can decrypt keychain items (not all of them). Extracts media files and app shared data.
  2. Extraction with a jailbreak: full file system extraction and keychain decryption. Only possible if a jailbreak is available for a given combination of iOS version and hardware.
  3. Extraction with checkra1n/checkm8: full file system extraction and keychain decryption. Utilizes a hardware exploit. Works on iOS 12.3-13.3.1. Compatibility is limited to A7..A11 devices (up to and including the iPhone X). Limited BFU extraction available if passcode unknown.
  4. Agent-based extraction: full file system extraction and keychain decryption. Does not require jailbreaking. Only possible for a limited range of iOS versions (iOS 11-12 except 12.3.1, 12.3.2, 12.4.1).

Prerequisites

Before you begin, you must have an Apple ID enrolled in Apple’s Developer Program in order to install the agent onto the iOS device being acquired. The Apple ID connected to that account must have two-factor authentication enabled. In addition, you will need to set up an Application-specific password in your Apple account, and use that app-specific password instead of the regular Apple ID password during the Agent installation.

Important: you can use your Developer Account for up to 100 devices of every type (e.g. 100 iPhones and 100 iPads). You can remove previously enrolled devices to make room for additional devices.

Using agent-based extraction

Once you have your Apple ID enrolled in Apple’s Developer Program, and have an app-specific password created, you can start with the agent.

 

  1. Connect the iOS device being acquired to your computer. Approve pairing request (you may have to enter the passcode on the device to do that).
  2. Launch Elcomsoft iOS Forensic Toolkit 5.30 or newer. The main menu will appear.
  3. We strongly recommend performing logical acquisition first (by creating the backup, extracting media files etc.)
  4. For agent-based extraction, you’ll be using numeric commands.
  5. Install the agent by using the ‘1’ (Install agent) command. You will have to enter your credentials (Apple ID and the app-specific password you’ve generated). Then type the ‘Team ID’ related to your developer account. Note that a non-developer Apple ID account is not sufficient to install the Agent. After the installation, start the Agent on the device and go back to the desktop to continue.
  6. Acquisition steps are similar to jailbreak-based acquisition, except that there is no need to use the ‘D’ (Disable lock) command. Leave the Agent (the iOS app) working in the foreground.
  7. Obtain the keychain by entering the ‘2’ command. A copy of the keychain will be saved.
  8. Extract the file system with the ‘3’ command. A file system image in the TAR format will be created.
  9. After you have finished the extraction, use the ‘4’ command to remove the agent from the device.

To analyse the file system image, use Elcomsoft Phone Viewer or an alternative forensic tool that supports .tar images. For analysing the keychain, use Elcomsoft Phone Breaker. For manual analysis, mount or unpack the image (we recommend using a UNIX or macOS system).

Conclusion

If you have unprocessed Apple devices with iOS 11 – 12.2 or 12.4, and if you cannot jailbreak for one or another reason, give the new extraction mode a try. iOS Forensic Toolkit 5.30 can pull the file system and decrypt the keychain, leaves no apparent traces, does not remount and does not modify the file system while offering safe, fast and reliable extraction.

We have updated Elcomsoft Cloud Explorer, our Google Account extraction tool, with Google Fit support. Google Fit is a relatively little known Google service aimed at tracking the user’s health and physical activities. In line with pretty much every other Google service, Google Fit synchronizes massive amounts of data with the user’s Google Account, storing activity-related information collected by all of the user’s devices in a single place. When extracting these data, we discovered massive amounts of location points stored alongside with information related to the user’s physical activities. Learn what is stored in Google Fit and how to extract it from the cloud!

What’s it all about

Google Fit extraction is about the massive amounts of data related to the user’s health and physical activities stored in the Google’s cloud. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can be truly invaluable during an investigation.

Google Fit is not the only type of information collected by Google. The search giant collects massive amounts of information. The types of data range from many years worth of the user’s location history to all of the user’s password saved in the Chrome browser or used with Android apps. Google Photos, Gmail, contacts and calendars, search requests and Web history, voice snippets, call logs and text messages and a lot more can make for some invaluable evidence. While Google readily returns most of that data when serving legal requests, Elcomsoft Cloud Explorer offers a much easier and near-instant extraction solution that requires far less paperwork. Considering the number of fully encrypted Android smartphones that may or may not be physically unlocked, Elcomsoft Cloud Explorer becomes truly irreplaceable, discovering more evidence than ever by revealing the hidden data one would never imagine existed, browsing deep inside into the user’s online activities going many years back. Elcomsoft Cloud Explorer does what Google itself does not do, offering a single point for downloading, discovering and analyzing evidence collected by Google.

How Google Fit collects information

Google Fit is both an app and a service. The Google Fit app is available for Android and iOS platforms; it can be used on both Android phones and Apple iPhones. The Google Fit service processes and stores information collected from all supported devices where it’s installed in the user’s Google Account.

While many users associate Google Fit with WearOS smartwatches, in reality the app does not require a smartwatch or a fitness tracker. A connected activity tracking device can provide information such as the number of steps walked, the number of stairs climbed, the user’s hear rate or periodic location points obtained from the tracker’s GPS sensor. When used without a compatible fitness tracker, the Google Fit app can source activity data from a smart combination of the phone’s built-in low-energy sensors, frequently obtained location points and a lot of artificial intelligence.

Google Fit data extracted from the user’s Google Account returns massive amounts of precise location points, allowing to pinpoint the user’s location with ultimate precision and granularity. Access to comprehensive location history and other critical real-time evidence can be vital for investigating crime.

Obtaining Google Account credentials

In order to sign in to the user’s Google Account, one requires the full set of Google credentials. The login and password can be often extracted from the user’s computer (with Elcomsoft Internet Password Breaker), from the cloud (with Elcomsoft Phone Breaker) or iOS keychain (with Elcomsoft iOS Forensic Toolkit).

In addition, some data from the Google Account (Google Fit being a notable exception) can be accessed with a token. The token is literally a cookie in Chrome, and can be extracted from the user’s computer. Elcomsoft Cloud Explorer includes a utility that automatically locates and extracts the authentication token from the Chrome browser installed on the user’s Mac or Windows PC. Using the extracted token, Elcomsoft Cloud Explorer authenticates into the user’s Google Account and displays the list of categories available for extraction.

Accessing Google Fit data

In order to extract Google Fit data from the user’s Google Account, you will need Elcomsoft Cloud Explorer 2.30 or newer.

  1. Launch Elcomsoft Cloud Explorer and create a new snapshot. Authenticate with the user’s login and password (Google Account). If required, pass two-factor authentication.
  2. Select the “Google Fit” check box.
  3. The data will be downloaded in several seconds to several minutes.
  4. After the processing, you can access Google Fit data from the main window.

Analyzing Google Fit data

You will be able to sort or group activities. The “Sessions” tab displays activity sessions detected by the Google Fit app. Activity sessions may include sleeping, walking, jogging and other types of activities.

Note that the sessions are detected automatically by the various apps and devices. Have a look at the “Package name” tab to discover which package has detected which session.

“Steps” can be either raw data from the connected smartwatch or fitness tracker, or information generated by the Google Fit app based on a combination of the smartphone’s step counter, the user’s height, and a lot of location data. If no external smartwatch or activity tracker is connected, the Google Fit app uses artificial intelligence to calculate the number of steps based on the abovementioned data. The app only polls the smartphone’s built-in step sensor at large intervals, relying more on location data than on the step counter.

Walking and running activities are automatically detected by the app based on the user’s heart rate, step count and location data.

One of the most interesting reports is “Locations”. By design, Google Fit collects massive amounts or location data. The test account reports 13,788 location points in 9 month. Considering that our test device was used on few rare occasions, the number of location reports is truly excessive. Clicking on a location point opens Google Maps.

Conclusion

Google Fit data may contain detailed information about the user’s location and physical conditions including the number of steps, types of activity, heart rate, elevation, and a lot more. Additional information provided by compatible health tracking devices may include blood pressure, elevation, precise step count, and additional location data collected from the GPS sensor built into the smartwatch or tracker. Analyzing the massive amounts of Google Fit data can become invaluable help when searching for evidence and investigating crime. The detailed, high-frequency location data collected by Google’s fitness app accompanied with information about the user’s physical condition can shed light on the user’s activities in a given timeframe.

How can you make your system and documents secure? Today, 256-bit AES encryption is offered by everyone and their dog. However, AES encryption does not mean much (or anything at all) when it comes to the real security of your data. Implementing encryption at the right time and in the right spot is no less important than choosing strong encryption credentials and managing the encryption keys.

While the previous part may sound a bit complicated, it all comes down to much simpler things than choosing the strongest encryption algorithm or selecting the length of the encryption key. If you are a Windows user, it all comes down to choosing the optimal data protection strategy for your particular usage scenario; protecting your storage media and the data you keep on them.

Defining your goals

Before you start considering encrypting your hard drives and files, make sure to define your objectives. What information would you like to protect? What threats do you consider important, less important and quite improbable?

Full-disk encryption part I: protecting your boot device

A reliable system protection is impossible without protecting your boot device. An unencrypted boot device (disk C: on most systems) allows for way too many vectors of attack ranging from hibernation and page file analysis to instant extraction of stored passwords from your Web browser vault. In other words, securing your boot device with BitLocker is an absolutely mandatory preliminary step and the most important security layer.

  • Availability: Windows 10 Professional and higher with TPM2.0, Intel PTT or Group Policy edit; all Windows editions for device encryption in thin and light devices meeting minimum requirements.
    • Note: although Windows 10 Home cannot natively create new BitLocker volumes, it can unlock BitLocker encrypted drives with full read-write access
  • Physical access, hard drive only: strong protection
  • Physical access, entire computer: it’s complicated
  • Other users on the same computer: not applicable
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

If your computer meets the requirements (namely, the presence of a hardware TPM2.0 module or software-based Intel Platform Trust Technology), enabling BitLocker on your computer can be as easy as opening the Control Panel and launching the BitLocker Drive Encryption applet. Note that not all editions of Windows 10 can use BitLocker protection.

We have a comprehensive article on BitLocker protection in our blog, which is highly recommended. Introduction to BitLocker: Protecting Your System Disk

What caveats are there when it comes to securing data against physical extraction? The thing is, while BitLocker is nearly a 100% effective solution for protecting the bare drive, it might not be as secure if the intruder has access to the entire computer with the hard drive installed. Even if your computer is equipped with a TPM2.0/Intel PTT module, Windows will still unlock the encrypted hard drive if Secure Boot conditions are met. This in turn opens numerous vectors of attack that may allow the intruder to intercept the on-the-fly BitLocker encryption key and decrypt the hard drive. These vectors of attack include:

  1. Making a RAM image of a running computer with BitLocker volume(s) mounted. This can be done via a Thunderbolt attack (Windows, by default, does not disable Thunderbolt DMA access when locked) or a cold boot attack.
  2. Breaking or extracting your Windows logon password (e.g. extracting from your Google account, your smartphone, or from another computer you have logged in and synced your data to).
  3. Obtaining your BitLocker Recovery Key from your Microsoft Account or Active Directory.

Advanced users and system administrators can read the following guide to secure their BitLocker volumes: BitLocker recovery guide

Full-disk encryption part II: protecting external storage devices

BitLocker is good not only for protecting your boot device, but for encrypting data on other volumes, built-in and removable. BitLocker protects external storage devices with BitLocker To Go, an encryption algorithm based on a password. In addition to passwords, external drives encrypted with BitLocker To Go have an option to unlock with a smart card on another computer by using BitLocker Drive Encryption in Control Panel. Finally, users can opt to make their encrypted external devices automatically unlock when connected to their (trusted) computer.

  • Availability:
    • Encrypt external devices: Windows 10 Professional and Enterprise
    • Access BitLocker encrypted devices: although Windows 10 Home cannot natively encrypt drives with BitLocker, it can access BitLocker encrypted drives with full read-write access
  • Physical access, device only: protection as strong as your password
  • Physical access, entire computer: it’s complicated (see previous chapter)
    • Note: if you enabled the option “Unlock automatically on this PC”, then effectively no protection
  • Other users on the same computer: strong protection if offline/not mounted
  • Malware/ransomware: strong protection if offline/not mounted
  • Online attacks: strong protection if offline/not mounted
  • Usage cases: protect data stored on external storage devices such as external drive enclosures, USB flash drives etc.

Unlike system drive encryption, BitLocker To Go does not support multifactor authentication. This means you cannot use TPM protection as an additional form of authentication. You can, however, make BitLocker To Go devices unlock automatically when they are inserted in your (trusted) computer, which carries obvious security implications.

Full-disk encryption part III: using third-party crypto containers

I put it here just for the sake of completeness. If you are considering using a crypto-container such as VeraCrypt or PGP, you probably know what it is good for and how to use it. I’ll just add several things that aren’t immediately obvious when you set up encryption. In fact, the two things are so non-obvious that many coach experts have it backwards. (The right way: Choosing the right hashing algorithm – it’s all about slowness).

  • Availability: VeraCrypt is available on most relevant platforms
  • Physical access, hard drive only: very strong protection unless misconfigured
    • Misconfiguration examples: volume stays mounted when computer sleeps or hibernates; volume stays mounted when computer is locked (matter of security vs. convenience); volume unlocked with security key (e.g. USB flash drive) and no password (if USB flash drive is discovered)
  • Physical access, entire computer:
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Other users on the same computer
    • volume not mounted at time of analysis: very strong protection
    • volume mounted: very little protection
  • Malware/ransomware: same as above
  • Online attacks: same as above
  • Usage cases: protect data against theft of computer or hard drive; protect data if hard drives are sold or RMA’d; protect data against physical extraction.

The choice of encryption algorithm (spoiler: use AES)

Crypto containers such as VeraCrypt offer the choice of several (actually, multiple) encryption algorithms that range from the industry-standard AES to some quite exotic algorithms such as Serpent or Kuznyechik. For the paranoiacs among us, VeraCrypt offers stacked encryption (e.g. the Serpent(AES) option). The thing is, the choice of an encryption algorithm does not affect the security of your data (unless you pick an algorithm with known or suspected vulnerabilities; finger pointed to Kuznyechik).

The choice of encryption algorithm does not affect the security of your data. A single round AES-256 encryption will be exactly as secure as Serpent(AES) or Serpent(Twofish(AES)). Moreover, the choice of encryption does not even affect the recovery speed (the speed of brute-force attacks on your password)!

Considering that AES is the only hardware-accelerated encryption algorithm in all reasonably modern processors, choosing any encryption algorithm other than AES-256 will unnecessarily slow down your reads and writes (expect a difference of 2 to 3 orders of magnitude in theoretical RAM-to-RAM encryption speeds) without providing any additional security benefit.

If choosing an encryption algorithm other than AES does not affect security, then what does?

The choice of hashing algorithm

When VeraCrypt encrypts (or decrypts) your data, it is using a binary encryption key to perform symmetric cryptographic operations. This media encryption key (MEK) is stored along with the encrypted data. The Media Encryption Key (MEK) is encrypted with a Key Encryption Key (KEK), which, in turn, is the result of multiple (hundreds of thousands) iterative hash operations performed on the user’s password.

In other words, when you type a password, the crypto container will perform a calculation of a certain hash function, and repeat that a 100,000 times or more (in order to deliberately slow down brute-force attacks).

If you want to make your encrypted volume more secure, you can change one of the two things:

  1. Increase the number of hash iterations
  2. Don’t use defaults
  3. Choose a slower hash function

VeraCrypt allows modifying the number of hash iterations by adjusting the PIM (Personal Iterations Multiplier); here is the how-to. The PIM value controls the number of iterations that is used to derive the encryption key from the password that you type. This value can be specified through the password dialog or in the command line. If you don’t manually specify the PIM value, VeraCrypt will use the default number of iterations, which is bad because (2). For SHA-512 or Whirlpool (the two recommended choices), VeraCrypt defaults to Iterations = 15000 + (PIM x 1000).

Why would you want to change the number of hash iterations? Because an attacker will first try to break your password using the defaults. Most tools used by the attackers to brute-force your password will first run the attack using all-defaults: the default encryption algorithm (AES), hash function (SHA-512) and PIM. Changing the PIM value is an easy way to substantially increase security without making your password more complex. Changing the hashing algorithm from default (SHA-512) to Whirlpool also makes sense in this context.

Which brings us to the choice of a hashing algorithm. VeraCrypt offers the choice of SHA-512 (slow, good choice), Whirlpool (slower, even better choice), SHA-256 (slow, but not as slow as SHA-512, use other hash instead), and Streebog (untested). Choosing the right hashing algorithm – it’s all about slowness has some benchmarks and some good explanations; highly recommended. Selecting Whirlpool makes a lot of sense because a) it is slower than SHA-512 (thus will be significantly slower to attack), and b) it is a non-default selection, which significantly increases the complexity of the attack.

File system encryption: when and how to use EFS

If you read the Wikipedia article about Microsoft Encrypting File System (EFS), you’ll get that EFS has been introduced in NTFS 3.0 in order to provides file system level encryption. The article reads: “The technology enables files to be transparently encrypted to protect confidential data from attackers with physical access to the computer.”

While all of that is interesting, neither statement explains who and, most importantly, why should be using EFS, and what exactly the encrypting file system protects against.

  • Availability: all versions and all editions of Windows 10 (and most older versions of Windows)
  • Physical access, hard drive only: as strong as your Windows account password
  • Physical access, entire computer: same as above
  • Other users on the same computer: effective protection
  • Malware/ransomware: not applicable
  • Online attacks: not applicable
  • Usage cases: protect your documents from other users of your computer; an extra layer of security on BitLocker-protected drives; reasonably strong, very easy and fully transparent document encryption on computers where BitLocker is not supported.

What does EFS protect against, and who should be using it?

The purpose of Encrypting File System is protecting your data from users who share your computer. If you have a PC with several users, and each user has their own Windows login (as opposed to sharing a single Windows account), activating EFS encryption is the easiest way to protect your files from being accessed by those other users.

What is the relation between EFS and BitLocker, and which one should you use?

BitLocker protects your entire system volume. Any user who can log in to your computer will unlock the system volume. If a user has administrative privileges (or can escalate a non-admin account by using an exploit), he or she will also gain access to files and documents stored in other users’ accounts on that computer.

Encrypting File System, on the other hand, only protects selected folders. It won’t, for example, protect your instant messenger databases or encrypt your browsing history. It’s mostly just for documents, pictures and videos you keep in your account. However, EFS will effectively protect those files against other users who can log on to your computer, even if they have administrative privileges.

If an attacker got physical access to the computer, BitLocker is the first line of defence. Relying solely on EFS to secure the PC against attacks with physical access is not the best idea.

How does it all work? It’s actually quite simple. Right-click on a file or folder you’d like to encrypt, select Properties and click the Advanced button in the General tab. In the Advanced Attributes dialog select Encrypt contents to secure data and click OK.

This is it. Windows will now encrypt the selected file or folder with your Windows logon credentials. There are no passwords to type and no encryption keys to save.

There is a certain drawback to using EFS encryption. If you ever forget your Windows password and have to reset it from a separate Administrator account (or your domain administrator resets the password for you), the EFS encryption keys will be lost, and you will be unable to decrypt your data without going through the data recovery process with Elcomsoft Advanced EFS Data Recovery. Note that you must recover your Windows password in order to decrypt the files. However, if you simply change your Windows password by following the normal procedure (typing your old password followed by entering the new one), you will be fine.

Document encryption

Encrypting individual documents is an important part of multi-layer security. Microsoft Office apps can use passwords to encrypt the documents’ content. No one without a password should be able to decrypt the document.

  • Availability: all versions of Microsoft Office
  • Security: depends on the version of Microsoft Office, the file format you’re using to save the files and the strength of your password.
  • Physical access, hard drive only: strong protection (with caveats)
  • Physical access, entire computer: strong protection (with caveats)
  • Other users on the same computer: strong protection (with caveats)
  • Other users on your Local Area Network: strong protection (with caveats)
  • Malware/ransomware: content protection. Malware won’t be able to decrypt your files and read your data. However, malware/ransomware can still encrypt your files, effectively locking you out.
  • Online attacks: content protection. Strong protection against unauthorized data access; no protection against unauthorized deletion
  • Usage cases: protect the content of your documents against anyone who does not know the encryption password.
  • How to: Protect a document with a password

A million dollar question: if you are on a local area network, should you use EFS or document encryption to protect documents against other users on the same LAN? In this case, it’s better to use both. EFS will make it impossible to gain access to encrypted files and folders without knowing your Windows account/domain credentials. Password protection of individual documents will make documents difficult to break even if the attacker knows your logon credentials.

The caveats of document encryption

So what exactly does “strong protection (with caveats)” mean? The thing is, your documents are just as secure as the password you use to protect them. If you re-use a password you already stored in your browser cache or in the keychain, extracting that password and decrypting the documents will be a matter of minutes in many types of attacks.

What if you use a cryptographically strong and truly unique password to encrypt documents? Are these documents secure? The thing is, they will be just as secure as the office app permits them to be. In Microsoft Office encryption evolution: from Office 97 to Office 2019 I discussed the encryption algorithms and protection strength of Microsoft Office apps from the early days to the most current release.

Generally speaking, everything before Office 2000 was insecure (no protection). Office 2000, XP and Office 2003 had very weak encryption that can be usually broken in under a day.

Since Office 2007, Microsoft started taking encryption seriously. Office 2010, 2013, 2016, 2019 brought security to the new level, making encrypted documents very secure.

Okay, so you are using the latest Office and selected a strong password; are we secure now? The thing is, you’ll be just as secure as the document format allows. If you are using the newer DOCX/XLSX format (files with .docx / .xlsx extensions), you’re good. If, however, you are saving your documents in “compatibility” mode, you are sacrificing encryption and make your documents as vulnerable as if they were saved by an Office 2003 app.

Best practices:

  1. Use the latest version of Microsoft Office to save documents. If the latest version is not available, use at least Office 2013 (the newer the better).
  2. Never save documents in “compatibility” mode. Make sure that the files are DOCX/XLSX as opposed to DOC/XLS.
  3. Use a unique, cryptographically strong password to encrypt documents. Remember: if the password is broken once (e.g. pulled from your Google account or recovered from a document you accidentally saved in the “compatible” format), it will be used to break everything else, including documents with strong encryption.
  4. If you email an encrypted document, do use a unique, one-time password for that document, and never send both the document and the password in the same email. In fact, you should never send the password by email since that would allow an attacker who gained access to your email account to decrypt the document. Send the document and the password via separate communication channels (e.g. email / text message, chat or phone call).

Protecting backups and archives

Making regular backups is a common wisdom. Protecting those backups is a wisdom much less common. Once you make a backup, make sure to give it as strong a protection as your boot drive.

  1. Store backups on BitLocker-protected media. Even if your backup tool (e.g. the one built into Windows) does not support encryption, at very least your storage media is protected with full-disk encryption. Note: Windows 10 does support the recovery from BitLocker-protected disks. Just create a bootable install image from Microsoft Web site (use “Create Windows 10 installation media”).
  2. If your backup tool supports encryption, it may be a good idea to encrypt your backups (AND store them on a BitLocker-protected media). Note, however, that a backup tool will probably cache (store) your backup password on your computer to automatically encrypt new and incremental backups. For this reason, make sure to have a truly unique, never reused password for encrypting backups.

Individual folders are frequently backed up using common archive tools such as WinZip, 7Zip or WinRar. All of these tools offer the ability to encrypt archives with a password. While the encryption strength is different among the three formats (ZIP, 7Z and RAR), an up to date version of each tool provides adequate protection if you choose a reasonably complex password (e.g. 8 characters or more, combining small and capital letters with numbers and special characters). To achieve the best level of protection, do keep those archives on BitLocker-protected media.

Note that password recovery tools work significantly faster on ZIP/7Z/RAR compared to attacking BitLocker encryption or Office 2013 (and newer) documents. For this reason, never reuse your password, and make sure that your BitLocker media, your documents and your backups/archives use very different passwords (ideally, not based on the same pattern).

More information:

Cloud security: OneDrive Personal Vault

Microsoft started offering an extra layer of security to all users of its cloud storage service in the form of a Personal Vault. OneDrive Personal Vault helps secure your files both on your computer and in the cloud in the event that someone gains access to your account or your device.

Unlike ransomware protection, Personal Vault is available to all users of Microsoft OneDrive and not just to Office 365 subscribers. Technically speaking, Personal Vault is an area in the OneDrive folder on your computer and in the OneDrive cloud storage that features additional protection. You can only access this protected area after passing a strong authentication. If your Microsoft Account is protected with two-factor authentication, you will have to pass the second step of identity verification in addition to typing your Microsoft Account password.

Once configured, Personal Vault must be manually unlocked every time you need access to secured data. To unlock, you must type in your Microsoft Account password and pass the second authentication step if your account has two-factor authentication. Once you’ve finished accessing the data, Personal Vault will automatically relock after a short period of inactivity. Once locked, any files you were using will also lock and require re-authentication to access.

Setting up Personal Vault only takes a few clicks as outlined in Protect your OneDrive files in Personal Vault.

OneDrive Personal Vault is still new; no independent security analysis has been performed until today. In our view, Personal Vault is worth consideration as an extra security layer for some of the most private but rarely accessed types of data. Examples of such data may include BitLocker escrow keys and binary encryption keys, or the list of passwords some users store in encrypted Excel spreadsheets. I personally keep my two-factor authentication secrets (scanned QR codes to initialize the Authenticator app) in the Vault as well.

  • Physical access: unknown (not yet analyzed)
  • Other users on the same computer: strong protection
  • Malware/ransomware: strong protection (unless Personal Vault is unlocked at the time malware is running)
  • Online attacks: as strong as your Microsoft Account security
  • Usage cases: activate to add an extra layer of security for a handful of personal documents, encryption keys, 2fa secrets etc.

 

Ransomware protection

One of the most important threats not covered by any encryption is the type of malware called ransomware. Ransomware is a type of malware that threatens to either publish the data stolen from the victim or perpetually block access to the victim’s files by encrypting them with a key that is only known to the attacker. The term ‘ransomware’ has emerged from the fact that, on many cases, attackers demand a ransom payment to decrypt data.

Protecting your data against ransomware is a complex topic in itself. However, computer users can choose one or both of the following two defences when it comes to ransomware protection.

Ransomware protection is effective against the following threats.

  • Physical access: no protection
  • Other users on the same computer: no protection
  • Malware/ransomware: effective protection
  • Online attacks: as strong as your cloud account security
  • Usage cases: available automatically to Office 365 subscribers. Available to paid Dropbox users. Automatically protects files stored in OneDrive/Dropbox. Automatic alerts (OneDrive only). Automatic restore (OneDrive only); manual restore (Dropbox).

Use cloud storage with automatic ransomware protection

If you are using Windows 10, most likely you already have a Microsoft Account. The Microsoft Account gives you access to OneDrive, Microsoft’s cloud storage solution. The free tier includes 5 to 15 GB of online storage, while Office 365 subscribers receive the whole terabyte of cloud storage.

Microsoft actively promotes OneDrive Ransomware Protection. OneDrive automatically detects when the files are mass-deleted or mass-edited (such as when ransomware encrypts the entire Documents folder), alerts the user and prompts to restore the known-good snapshot. The File Restore feature is only available to Office 365 subscribers (Home and Personal levels are enough to receive protection).

More information at Ransomware detection and recovering your files.

If you prefer Dropbox to Microsoft OneDrive, Dropbox gets you covered against ransomware attacks, but mostly for higher-level paid tiers. Users of the free Basic tier as well as Plus subscribers can roll back individual encrypted files during the first 30 days after the attack (there will be no warning of mass-deletion of mass-encryption of files coming from the Dropbox app). If you want to roll back the entire Documents folder with Dropbox Rewind, you’ll need to be a paid Plus or Professional tier subscriber.

More information:

Make backup snapshots. Keep backup media offline

Once ransomware is installed on your computer, it will try to encrypt every document that is accessible. The obvious solution is making documents inaccessible by physically disconnecting backup media (such as using 2.5” portable USB drives to back up). In this scenario, you would only connect backup media to your computer when you actually want to make the backup, disconnecting the disk after the backup tool finishes its job. With this approach, even if your computer is attacked by ransomware, your offline backups will not be affected (unless you connected the external drive to the computer at the time the ransomware was installed).

In addition, configure your backup tool to keep snapshots of your data going back as long as permitted by available storage. In our office, an affordable 4TB USB hard drive can keep approximately 30 to 40 full snapshots of the Documents folder; this number becomes significantly larger if you enable incremental backups, with each snapshot saving only

More information:

 

If you are a Windows user and ever considered protecting your data with full-disk encryption, you have probably heard about BitLocker. BitLocker is Microsoft’s implementation of full-disk encryption that is built into many versions of Windows. You maybe even using BitLocker without realizing that you do – for example, if you have a Surface or a similar thin-and-light Windows device. At the same time, BitLocker encryption is not available by default on desktops if you are using the Home edition of Windows 10. Activating BitLocker on your system disk can be tricky and may not work right away even if your Windows edition supports it. In this article, we are offering an introduction to BitLocker encryption. We’ll detail the types of threats BitLocker can effectively protect your data against, and the type of threats against which BitLocker is useless. Finally, we’ll describe how to activate BitLocker on systems that don’t meet Microsoft’s hardware requirements, and evaluate whether it’s worth it or not security-wise.

Threats Covered by BitLocker Encryption

BitLocker encryption is not the be-all and end-all type of protection. While BitLocker securely encrypts your data with industry-standard AES encryption, it can only protect your data against a set of very specific threats.

BitLocker can effectively protect your data in the following circumstances.

Your hard drive(s) are removed from your computer

If, for any reason, your hard drives (or SSD drives) are removed from your computer, your data is securely protected with a 128-bit encryption key (users requiring higher-level security can specify 256-bit encryption when setting up BitLocker).

How secure is this type of protection? If you’re using TPM protection (more on that later), it is very secure; just as secure as the AES algorithm itself (in layman view, 128-bit or 256-bit encryption are equally strong).

If, however, you have enabled BitLocker on a computer without TPM, then BitLocker encryption will be just as secure as the password you set. For this reason, make sure to specify a reasonably strong, reasonably long and absolutely unique password.

The entire computer is stolen

If your entire computer is stolen, the security of your data depends on the type of BitLocker protection you are using as well as on the strength of your Windows password. The most convenient method is “TPM only” (more on that later); this is the least secure method as well, because your computer will decrypt the hard drive(s) before you sign in to Windows.

If you are using “TPM only” protection policy, anyone who knows your Windows account password (or your Microsoft Account password, if you are using a Microsoft Account as your Windows 10 login) will be able to unlock your data.

TPM + PIN is significantly more secure; in a way, it is practically as secure as a bare hard drive.

If you set up BitLocker protection without a TPM or Intel PTT installed, you’ll be forced to using the password. In this case, the data will be as secure as your password. BitLocker is designed to slow down brute-force attacks, so even a 8-character password can provide secure protection to your data.

Other users on the same computer

 If anyone can log in to your computer and access their account, the disk volume has been already decrypted. BitLocker does not protect against peer computer users.

Malware/ransomware and online threats

 BitLocker does nothing to protect your data against malware, ransomware or online threats.

In other words, BitLocker is great when protecting your data against the removal of the hard drive(s); it’s perfect if you want to protect your data if you sell or RMA your hard drives. It’s somewhat less effective (depending on your policies) when protecting your data if the entire computer is stolen. This is it; other usage cases are not covered.

System Requirements

Most of us are used to “System Requirements” being a mere formality. This is not the case with BitLocker. In order to protect your boot device with BitLocker, you must be running Windows 10 Professional or higher. Windows 10 Home does not support BitLocker system encryption.

To make things more confusing, Microsoft does support BitLocker device protection even on devices with Windows 10 Home. Effectively, this is the same encryption, just with some limitations. BitLocker device protection is available on thin and light devices (e.g. Microsoft Surface) supporting Connected standby and equipped with solid-state storage. Those devices must be equipped with a TPM2.0 module or Intel PTT technology.

If you are using Windows 10 Professional or higher with TPM2.0 or Intel PTT, you can enable BitLocker straight away. However, most computers are not equipped with TPM modules, and only newer-generation computers (think Intel 8th and 9th Gen motherboards; some higher-end motherboards may support Intel PTT with older processors) support Intel Platform Trust Technology. Intel PTT is not even enabled in BIOS by default; you must manually enable the thing to use it for BitLocker protection.

Here’s how you activate Intel PTT on Gigabyte Z390 boards (latest BIOS):

 

Alternatively, you can perform a Group Policy edit to enable BitLocker without hardware protection modules.

If your computer meets the requirements (namely, the presence of a hardware TPM2.0 module or software-based Intel Platform Trust Technology), enabling BitLocker on your computer can be as easy as opening the Control Panel and launching the BitLocker Drive Encryption applet. Note that not all editions of Windows 10 can use BitLocker protection.

Once you click on “Turn on BitLocker”, Windows will prompt you to create an escrow key (BitLocker Recovery Key). It is highly advisable to do so. On a balance, storing the recovery key in your Microsoft Account might be a good enough option for most home users, while employees will store their recovery keys in their company’s Active Directory. Saving the key into a file or printing it out are also valid options that will provide just as much security as your personal safe box.

Thin and light devices (such as Windows tablets and ultrabooks) may be protected with device encryption as opposed to BitLocker Drive Encryption. The algorithm is essentially the same; however, the compatibility requirements are different. Device encryption is available for thin and light devices running any Windows 10 edition, while BitLocker Drive Encryption is not available to Windows 10 Home users. If you have data to protect, you’ll need to pay a fee for an in-place upgrade to Windows 10 Professional.

What if you already have Windows 10 Professional but don’t have a hardware TPM2.0 module? If you are using one of the latest boards based on Intel chip sets, you may be able to activate Intel Platform Trust Technology (How To Enable BitLocker With Intel PTT and No TPM For Better Security) or perform the following Group Policy edit to enable BitLocker:

  1. Open Group Policy Editor (type gpedit.msc in the Windows Search box)
  2. Open Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives
  3. Edit the Require additional authentication at startup policy
  4. Set the policy to Enabled and check Allow BitLocker without a compatible TPM as shown on the screen shot

Speaking of the policies, BitLocker supports various methods of authentication, each offering a unique trade-off between security and convenience.

  • TPM only. Your system will boot to login prompt; the data will be decrypted with a key stored in the TPM (or Intel PTT) module. This is the most convenient option that effectively protects hard drives, but offers weaker protection if the intruder has access to the whole system (computer with TPM and the hard drive).
  • TPM + PIN. In this mode, the TPM module will only release the encryption key if you correctly type the PIN code during pre-boot phase. Even though the PIN code is short, entering the wrong PIN several times makes TPM panic and block access to the encryption key. This option arguably offers the best balance between security and convenience, combining “something that you have” (the TPM module) with “something that you know” (the PIN code). At the same time, this option may not be convenient in multi-user environments.
  • TPM + USB Key. This option requires both the TPM and a USB flash drive (or CCID smartcard) to be present in order for the system to boot.
  • TPM + PIN + USB Key. Just as the name suggests, this option requires all three of the TPM, PIN code and USB key/smartcard in order to boot your computer. While this is probably the most secure option, the additional security benefits are hardly worth it compared to the TPM + PIN option if you consider the reduced convenience and reliability (you’ll have to use the recovery key if a USB key or smart card gets lost or corrupted).
  • USB Key. This option is only recommended if your computer is not equipped with a TPM module and does not support the Intel PTT.
  • Password only. Just like the previous option, “password only” authentication should only be used if no TPM or Intel PTT is available. Note that the “password” option is different from the “PIN” as there is no enforceable limit on the number of password attempts without a TPM, which allows a brute-force attack on the password.

Advanced users and system administrators can refer to BitLocker Group Policy settings in Microsoft Knowledge Base.

What caveats are there when it comes to securing data against physical extraction? The thing is, while BitLocker is nearly a 100% effective solution for protecting the bare drive, it might not be as secure if the intruder has access to the entire computer with the hard drive installed. Even if your computer is equipped with a TPM2.0/Intel PTT module, Windows will still unlock the encrypted hard drive if Secure Boot conditions are met. This in turn opens numerous vectors of attack that may allow the intruder to intercept the on-the-fly BitLocker encryption key and decrypt the hard drive. These vectors of attack include:

  1. Making a RAM image of a running computer with BitLocker volume(s) mounted. This can be done via a Thunderbolt attack (Windows, by default, does not disable Thunderbolt DMA access when locked) or a cold boot attack.
  2. Breaking or extracting your Windows logon password (e.g. extracting from your Google account, your smartphone, or from another computer you have logged in and synced your data to).
  3. Obtaining your BitLocker Recovery Key from your Microsoft Account or Active Directory.

Advanced users and system administrators can read the following guide to secure their BitLocker volumes: BitLocker recovery guide

Conclusion

Reliable data protection is impossible without protecting your boot device. BitLocker is the perfect choice. It’s secure, convenient and highly configurable, allowing you balance security and convenience to your precise requirements. If you are concerned about security of your data, protecting your boot device with BitLocker is an absolutely mandatory step and the most important security layer.

 

Today’s smartphones collect overwhelming amounts of data about the user’s daily activities. Smartphones track users’ location and record the number of steps they walked, save pictures and videos they take and every message they send or receive. Users trust smartphones with their passwords and login credentials to social networks, e-commerce and other Web sites. It is hard to imagine one’s daily life without calendars and reminders, notes and browser favorites and many other bits and pieces of information we entrust our smartphones. All of those bits and pieces, and much more, are collected from the iPhone and stored in the cloud. While Apple claims secure encryption for all of the cloud data, the company readily provides some information to the law enforcement when presented with a legal request – but refuses to give away some of the most important bits of data. In this article we’ll cover the types of data that Apple does and does not deliver when served with a government request or while processing the user’s privacy request.

What’s Stored in iCloud

Apple uses iCloud as an all-in-one cloud backup, cloud storage and cloud synchronization solution for the user of iOS, iPasOS and macOS devices. iOS 12 and 13 can store the following types of data in the user’s iCloud account:

iCloud backups

iCloud backups contain a lot of data from the iPhone, which includes device settings and home screen icons, the list of installed apps and individual apps’ private data (if allowed by the app developer).

The content of iCloud backups is mostly exclusive. Many types of data that are synchronized with iCloud will be excluded from cloud backups. For example, if the user enables the iCloud Photo Library, pictures and videos will synchronize to iCloud and will not be included in iCloud backups. The same is true for many other categories. Here’s what Apple says in What does iCloud back up?

Your iPhone, iPad, and iPod touch backup only include information and settings stored on your device. It doesn’t include information already stored in iCloud, like Contacts, Calendars, Bookmarks, Mail, Notes, Voice Memos, shared photos, iCloud Photos, Health data, call history, and files you store in iCloud Drive.

In iOS 13, iCloud backups do not include any of the following:

  • Keychain *
  • Health data
  • Home data
  • iCloud Photos **
  • Messages **
  • Call logs
  • Safari history

* While the keychain is still physically included, records marked as ThisDeviceOnly are encrypted with a device-specific key and can only be restored onto the same physical device they were saved from.

** Photos and Messages are not included if (and only if) the iCloud sync of those categories is not enabled in device settings.

Synchronized data

iOS allows synchronizing many types of data with the user’s iCloud account. While users can enable or disable the sync for some of the data categories (as defined in Change your iCloud feature settings), some other types of data (e.g. the call log) are always synchronized unless the user disables the iCloud Drive feature entirely.

The following types of data are synchronized to iCloud:

  • Photos
  • Safari History & Bookmarks
  • Calendars
  • Contacts
  • Find My (Devices & People)
  • Notes
  • Reminders
  • Siri Shortcuts
  • Voice Memos
  • Wallet passes
  • iCloud Mail
  • Maps
  • Clips
  • Data covered by the iCloud Drive category (e.g. Call logs)

Files

There are two distinct data types that fall under the “Files” category.

The first category includes files the user stores in their iCloud Drive (e.g. by using the iOS Files app). These files are user-accessible, and can be downloaded by using the iCloud Drive app on a Mac or Windows PC.

The second category includes files stored by system apps (e.g. downloaded books and documents in the Books app) and third-party apps (e.g. stand-alone WhatsApp backups, game saves etc.) While large amounts of data may accumulate under this category, users have no direct access to these files. For example, any files stored by third-party apps are only displayed as toggles in the iCloud | Apps section. The only control the user has over these files is the ability to disable sync (and remove stored files) for a certain app.

End-to-end encrypted data

Apple uses end-to-end encryption to secure sensitive types of data such as the users’ passwords, Health data or credit card information. The data is secured with an encryption key derived from some device-specific information and the user’s screen lock passcode. Users must enroll their devices into the trusted circle in order to enable the sharing of end-to-end encrypted data.

The following types of data are covered by end-to-end encryption as per iCloud security overview:

  • Home data
  • Health data (iOS 12 or later) *
  • iCloud Keychain (includes saved accounts and passwords)
  • Payment information
  • QuickType Keyboard learned vocabulary (iOS 11 or later)
  • Screen Time password and data
  • Siri information
  • Wi-Fi passwords
  • Messages in iCloud **

* iOS 11 devices synchronize Health data as a regular data category without using end-to-end encryption. According to Apple, “End-to-end encryption for Health data requires iOS 12 or later and two-factor authentication. Otherwise, your data is still encrypted in storage and transmission but is not encrypted end-to-end. After you turn on two-factor authentication and update iOS, your Health data is migrated to end-to-end encryption.”

** According to Apple, “Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn’t stored by Apple. Since iOS 13, Apple no longer stores Messages in iCloud backups if the user activates Messages in iCloud.

What Apple Provides When Serving Government Requests

Apple discloses certain types of information when serving a valid government request. This data typically includes information that falls into iCloud backups, Synchronized data and Files categories.

When serving government requests, Apple also delivers iCloud backups. End users exercising their rights under the European Data Protection Directive (EDPR) or requesting their personal data via Apple’s Data & Privacy portal do not receive a copy of their iCloud backups.

The following principles apply when Apple serves government requests: https://www.apple.com/privacy/government-information-requests/; of particular interest are the following excerpts:

Apple will notify customers/users when their Apple account information is being sought in response to a valid legal request from government or law enforcement, except where providing notice is explicitly prohibited by the valid legal request, by a court order Apple receives, by applicable law or where Apple, in its sole discretion, believes that providing notice creates a risk of injury or death to an identifiable individual, in situations where the case relates to child endangerment, or where notice is not applicable to the underlying facts of the case, or where Apple reasonably considers that to do so would likely pervert the course of justice or prejudice the administration of justice.

The second category includes files stored by system apps (e.g. downloaded books and documents in the Books app) and third-party apps (e.g. stand-alone WhatsApp backups, game saves etc.) While large amounts of data may accumulate under this category, users have no direct access to these files. For example, any files stored by third-party apps are only displayed as toggles in the iCloud – Apps section. The only control the user has over these files is the ability to disable sync (and remove stored files) for a certain app.

Apple defines information provided to the LE as follows:

iCloud stores content for the services that the subscriber has elected to maintain in the account while the subscriber’s account remains active. Apple does not retain deleted content once it is cleared from Apple’s servers. iCloud content may include email, stored photos, documents, contacts, calendars, bookmarks, Safari browsing history, Maps Search History, Messages and iOS device backups. iOS device backups may include photos and videos in the Camera Roll, device settings, app data, iMessage, Business Chat, SMS, and MMS messages and voicemail. All iCloud content data stored by Apple is encrypted at the location of the server. When third-party vendors are used to store data, Apple never gives them the keys. Apple retains the encryption keys in its U.S. data centres.

While Apple correctly claims that it does not keep deleted content once it is cleared from Apple’s servers, we have found that, in many cases, some content may still be available on Apple servers. As a result, tools such as Elcomsoft Phone Breaker can access and download such content.

Additionally, Apple does not explicitly mention certain types of data such as the phone-to-cloud communication logs. These logs record the phone’s dynamic IP address and store records going back some 28 days.

What Apple Provides When Serving Privacy Requests

Apple is committed to disclosing information to end users according to the European Data Protection Directive (EDPR) or serving a request for personal data submitted via Apple’s Data & Privacy portal. Users can request a download of a copy of their data from Apple apps and services. This, according to Apple, may include purchase or app usage history and the data users store with Apple, such as calendars, photos or documents. Below is the list of information disclosed by Apple:

Note: iCloud backups are only provided when Apple serves government requests. End users exercising their rights under the European Data Protection Directive (EDPR) or requesting their personal data via Apple’s Data & Privacy portal do not receive a copy of their iCloud backups.

What Apple Does Not Provide

Any information that falls under the End-to-end encrypted data category as defined in the iCloud security overview is never disclosed to the law enforcement. End users may only obtain end-to-end encrypted data by setting up a compatible Apple device and typing a screen lock passcode of their past device.

Obtaining End-to-End Encrypted Data

Since Apple refuses to provide legal access to any of the data the company protects with end-to-end encryption, experts must use third-party tools to extract this information from iCloud. Elcomsoft Phone Breaker is one of the few tools on the market that can touch these encrypted categories. Elcomsoft Phone Breaker can extract the iCloud backups, files and synchronized data. In addition, the tool can download and decrypt the following types of end-to-end encrypted data:

  • iCloud Keychain
  • Health
  • Messages in iCloud
  • Screen Time password
  • FileVault2 recovery token

In order to access end-to-end encrypted data, the following information is required:

  1. The user’s Apple ID and password
  2. A valid, non-expired one-time code to pass Two-Factor Authentication
  3. The user’s screen lock passcode or system password to any current or past device enrolled in the trusted circle

More information:

Conclusion

In this article, we described the discrepancy between the data Apple collects from its users and stores on its servers, and the data the company gives away to the law enforcement when serving a government request. Some of the most essential categories are not disclosed, particularly the user’s passwords (iCloud Keychain), text messages and iMessages (Messages in iCloud), the user’s physical activity logs (Health), device usage patterns (Screen Time) and Home data. Most of this information can be only accessed by using third-party tools such as Elcomsoft Phone Breaker, and only if the complete set of authentication credentials (the login and password, 2FA code and screen lock/system password) are known.

What is DFU, and how is it different from the recovery mode? How do you switch the device to recovery, DFU or SOS mode, what can you do while in these modes and what do they mean in the context of digital forensics? Can you use DFU to jailbreak the device and perform the extraction if you don’t know the passcode? Read along to find out.

iOS Recovery Mode

The recovery mode is the easiest to explain. According to Apple, you can put your iOS or iPadOS device in recovery mode to restore it using your computer.

The recovery mode comes handy if one of the following situations occurs:

  • Your iOS or iPadOS device is locked after multiple unsuccessful unlock attempts and displays the infamous “Connect to iTunes” message. In many cases, connecting the device to iTunes will be unsuccessful because the data connection of the device is blocked with USB restricted mode. If this is the case, you must switch the device to recovery mode and connect to iTunes to restore.
  • You forgot the screen lock passcode and want to reset the device to factory settings. Activation lock: following the reset, you’ll have to provide the Apple ID/iCloud password of the device’s Apple ID account.
  • The device cannot fully boot; the display is stuck on the Apple logo for several minutes with no progress bar. I have personally seen this multiple times after unsuccessful iOS updates (the latest case being the almost-full iPhone 7 updated from iOS 9 straight to the latest iOS 13.3).
  • Your computer doesn’t recognize your device or says it’s in recovery mode, or you see the recovery mode screen.

How to switch the device into recovery mode

The recovery mode is well-documented in “If you can’t update or restore your iPhone, iPad, or iPod touch” (link). Connect the device to a computer with iTunes installed. Perform a force restart of the device by following instructions laid out in “If your screen is black or frozen” (link):

If your screen is black or frozen

If your screen is black or frozen, you might need to force-restart your device. A force-restart won’t erase the content on your device. You can force-restart your device even if the screen is black or the buttons aren’t responding. Follow these steps:

  • iPad models with Face ID: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then press and hold the Power button until the device restarts.
  • iPhone 8 or later: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then press and hold the Side button until you see the Apple logo.
  • iPhone 7, iPhone 7 Plus and iPod touch (7th generation): Press and hold both the Top (or Side) button and the Volume Down buttons until you see the Apple logo.
  • iPad with Home button, iPhone 6s or earlier and iPod touch (6th generation) or earlier: Press and hold both the Home and the Top (or Side) buttons until you see the Apple logo.

After following the force-restart instructions, do not release the buttons when you see the Apple logo, wait until the recovery mode screen appears:

  • iPad models with Face ID: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Press and hold the Top button until your device begins to restart. Continue holding the Top button until your device goes into recovery mode.
  • iPhone 8 or later: Press and quickly release the Volume Up button. Press and quickly release the Volume Down button. Then, press and hold the Side button until you see the recovery mode screen.
  • iPhone 7, iPhone 7 Plus, and iPod touch (7th generation): Press and hold the Top (or Side) and Volume Down buttons at the same time. Keep holding them until you see the recovery mode screen.
  • iPad with Home button, iPhone 6s or earlier, and iPod touch (6th generation) or earlier: Press and hold both the Home and the Top (or Side) buttons at the same time. Keep holding them until you see the recovery mode screen.

(source)

How to use the recovery mode

We know of several viable usage scenarios for the recovery mode.

  1. Reinstall iOS (if the iOS device is running the latest version), perform an in-place update or switch from a beta version of iOS to the current release version using the iTunes app. In this scenario, the data is preserved.
  2. Restore the device. This is what you want if you forgot the passcode. The passcode will be removed and USB restrictions disabled, but the data will be already erased by that time. Mind the activation lock.
  3. Perform a (limited) forensic extraction through recovery mode. You’ll need a reasonably up to date version of iOS Forensic Toolkit (EIFT 4.10 or newer).

Information available in recovery mode

When performing a forensic extraction of a device running in the recovery mode, note that only a very limited set of data will be available. The following information is available:

Device Model: iPhone8,1
Model: n71map
ECID: XXXXXXXXXXXXXXXX
Serial Number: XXXXXXXXXXX
IMEI: XXXXXXXXXXXXXXX
MODE: Recovery

The Recovery mode may return the following information:

  • Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
  • ECID (UCID): XXXXXXXXXXXXXXXX. The ECID (Exclusive Chip Identification) or Unique Chip ID is an identifier unique to every unit, or more accurately, to every SoC.
  • Serial number: XXXXXXXXXXX (or N/A)
  • IMEI: XXXXXXXXXXXXXXX (or N/A). Note that we have not seen IMEI information on any of our test devices, with or without a SIM card.
  • Mode: Recovery

How to exit recovery mode

The procedure for leaving the recovery mode is different for different devices. In general, you’ll use the following steps:

  • Unplug the USB cable.
  • Hold down the sleep/wake button or side button depending on device model until the device turns off.
  • Either keep holding the button combination or release and hold it down again until the Apple logo appears.
  • Let go of the buttons and let the device start up.

This is the Apple-recommended procedure for exiting the recovery mode:

  • iPhone 6s and earlier, Touch ID equipped iPads: hold the Home button and the Lock button until the device reboots.
  • iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.
  • iPhone 8 and newer: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

Forensic implications of iOS recovery mode

The recovery mode has a positive yet limited value for mobile forensic specialists.

  • Enables obtaining device information without a passcode.
  • Allows bypassing the USB restricted mode (albeit accessing limited amounts of information).
  • For newer iOS devices (A12 and newer), returns more information compared to the DFU mode.

Interestingly, when users install the checkra1n jailbreak from the device GUI, the jailbreak first switches the device into recovery (unlike DFU, the recovery mode is available through the API). Only after the device is switched to recovery, the jailbreak prompts for a switch to DFU and displays step-by-step instructions and timings. Alternatively, the jailbreak can be installed from the command line, which will bypass the intermediary recovery mode.

iOS DFU Mode

The undocumented DFU stands for “Device Firmware Upgrade”. Unlike the recovery mode, which is designed with an ordinary user in mind, the DFU mode was never intended for the public. There is no documentation about DFU anywhere in Apple Knowledge Base. Entering the DFU more involves a complicated sequence of pressing, holding and releasing buttons with precise timings. Wrong timings during any of the multiple steps would reboot the device instead of switching it to DFU. Finally, there is no on-screen indication of DFU mode. If the device is successfully switched to DFU, the display remains black. Entering DFU mode can be difficult even for experts.

DFU is part of the bootrom, which is burned into the hardware. On A7 through A11 devices, a vulnerability has been discovered allowing to bypass SecureROM protection and jailbreak the device via DFU mode. More in our blog: BFU Extraction: Forensic Analysis of Locked and Disabled iPhones.

Steps for entering DFU mode differ between devices. Some devices have several different methods to invoke DFU, making it even more confusing. The differences in procedures may be severe between device generations. Since no official instructions are available, we have to rely on third-party sources for information.

Note: the device screen will be completely black while in DFU mode. The iPhone Wiki explains steps required to enter the DFU mode in a dedicated article. According to the article, this is how you enter DFU mode on the different device models. If you are more of a visual learner, check out this link with video tutorials instead: How To Put An iPhone In DFU Mode, The Apple Way

Apple TV

  1. Plug the device into your computer using a USB cable.
  2. Force the device to reboot by holding down the “Menu” and “Down” buttons simultaneously for 6-7 seconds.
  3. Press “Menu” and “Play” simultaneously right after reboot, until a message pops up in iTunes, saying that it has detected an Apple TV in Recovery Mode.

A9 and older devices (iPad other than the ones listed below, iPhone 6s and below, iPhone SE and iPod touch 6 and below)

  1. Connect the device to a computer using a USB cable.
  2. Hold down both the Home button and Lock button.
  3. After 8 seconds, release the Lock button while continuing to hold down the Home button.
    • If the Apple logo appears, the Lock button was held down for too long.
  4. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

Alternative method 1:

  1. Hold the Lock Button for 3 seconds
  2. Continue holding the Lock button and also hold the Home button (15 seconds)
  3. Release the Lock button while continuing to hold the Home button (10 seconds)
  4. Your device should enter DFU mode

Alternative method 2:

  1. Connect the device to your computer and launch iTunes. Turn the device off.
  2. Hold down the Lock button and Home button together for exactly 10 seconds, then release the Lock button.
  3. Continue holding the Home button until iTunes on your computer displays a message that a device in recovery mode has been detected. The device screen will remain completely black.

A10 devices (iPhone 7 and iPhone 7 Plus, iPad 2018, iPod touch 7)

  1. Connect the device to a computer using a USB cable.
  2. Hold down both the Side button and Volume Down button.
  3. After 8 seconds, release the Side button while continuing to hold down the Volume Down button.
    • If the Apple logo appears, the Side button was held down for too long.
  4. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

A11 and newer devices (iPhone 8 and above, including the iPhone Xr, Xs and Xs Max; iPad Pro 2018, iPad Air 2019, iPad Mini 2019)

  1. Connect the device to a computer using a USB cable.
  2. Quick-press the Volume Up button
  3. Quick-press the Volume Down button
  4. Hold down the Side button until the screen goes black, then hold down both the Side button and Volume Down button.
  5. After 5 seconds, release the Side button while continuing to hold down the Volume Down button.
    • If the Apple logo appears, the Side button was held down for too long.
  6. Nothing will be displayed on the screen when the device is in DFU mode. If open, iTunes will alert you that a device was detected in recovery mode.
    • If your device shows a screen telling you to connect the device to iTunes, retry these steps.

If your device shows a screen telling you to connect the device to iTunes, retry these steps.

Sources: iphonewiki and other third-party sources

Information available in DFU mode

The DFU mode returns even less information compared to the recovery mode.

Device Model: iPhone8,1
Model: n71map
ECID: XXXXXXXXXXXXXXXX
Serial Number: N/A
IMEI: N/A
MODE: DFU

To obtain this information, use iOS Forensic Toolkit 4.10 or newer.

  • Device model: two representations of the device model, e.g. iPhone7,2 (n61ap), iPhone10,6 (d221ap) etc.
  • ECID/Unique Chip ID: XXXXXXXXXXXXXXXX
  • Serial number: not available in DFU mode
  • IMEI: not available in DFU mode
  • Mode: DFU
  • Exiting DFU Mode

How to exit DFU mode

The process of exiting DFU mode is also different across devices.

For devices with a physical Home button (up to and including iPhone 6s and iPhone SE): hold the Home button and the Lock button until the device reboots.

For iPhone 7 and iPhone 7 Plus: hold down the Side button and Volume Down button until the device reboots.

For iPhone 8 and iPhone 8 Plus, iPhone X: click the Volume Up button, then click the Volume Down button, then hold down the Side button until the device reboots.

Forensic implications of DFU mode

The DFU mode may have a huge value for mobile forensic specialists depending on the device model. iPhone, iPod Touch and iPad devices based on A5 through A11 generations of Apple processors (iPhone generations from iPhone 4s through iPhone 8, 8 Plus and iPhone X, as well as the corresponding iPad models) have a non-patchable, hardware-based bootrom vulnerability. This vulnerability allows installing a jailbreak on affected devices regardless of the version of iOS that is installed. This also makes it possible to extract a limited but still significant amounts of data through DFU mode without knowing or breaking the passcode.

  • All devices: enables obtaining device information without a passcode
  • All devices: allows bypassing the USB restricted mode (albeit accessing limited amounts of information)
  • Vulnerable iOS devices (A5 through A11 generations): returns significantly more information compared to the recovery mode
  • Criminals exploit the vulnerability to remove Activation Lock from vulnerable devices (A5 through A11 generations) running older versions of iOS. Reportedly, this vulnerability has been fixed by Apple in iOS 13.3; however, considering the nature of the exploit, this functionality may reappear.

The following information is extractable from vulnerable iOS devices:

  • Limited file system extraction: the list of installed applications, some Wallet data, the list of Wi-Fi connections, some media files, notifications (these may contain some chat messages and other useful data), and many location points.
  • Keychain records with kSecAttrAccessibleAlways and kSecAttributeAccessibleAlwaysThisDeviceOnly
  • Oxygen Forensic Detective additionally processes files such as /private/var/wireless/Library/Databases/DataUsage.sqlite (apps’ network activities), /private/var/preferences/ (network interfaces) or /private/var/mobile/Library/Voicemail/ (voicemail messages) to display even more information.

More information in BFU Extraction: Forensic Analysis of Locked and Disabled iPhones and iOS Device Acquisition with checkra1n Jailbreak.

Differences between DFU and recovery modes

While both DFU and recovery are designed to fulfil essentially the same goal of recovering a non-bootable device by flashing known working firmware, they are very different in the way they work.

The recovery mode boots into the bootloader (iBoot), and works by issuing commands through the bootloader. The bootloader is part of the operating system, and can be flashed, updated or patched if there are any vulnerabilities discovered. The recovery mode will only accept signed firmware images, so going back to firmware that is no longer signed by Apple is not possible. While the device is in recovery mode, the user gets a clear visible indication on the device:

DFU or Device Firmware Upgrade, on the other hand, allows restoring devices from any state, including devices with corrupted bootloader. DFU does not operate through a software-upgradeable bootloader. Instead, DFU is burned into the hardware as part SecureROM. DFU cannot be updated, patched or disabled. As a result, the bootrom vulnerability and the corresponding checkm8 exploit cannot be patched by Apple, allowing experts extract certain data from affected devices while bypassing passcode protection and USB restrictions.

DFU will also accept only signed firmware packages. As long as a package is still signed by Apple, the user can upgrade and downgrade firmware at will since there is no downgrade protection in DFU. There is no indication on the device that the device is in DFU mode. During DFU interfacing, the device screen remains black.

The recovery mode was designed for end users and Apple facilities, while the DFU mode was never meant for the end user at all. Entering the recovery mode is easy; any reasonably experienced user can follow the instructions. Entering the DFU mode is not only significantly trickier, but requires precise timings. Hold a button one second too long, and the device simply reboots instead of entering DFU.

The S.O.S. mode

The third and final special mode we’re about to discuss today is the S.O.S. mode. The S.O.S. mode can be manually invoked by the user while the device is running. Apple has a comprehensive description of S.O.S. mode in Use Emergency SOS on your iPhone.

Activating S.O.S. mode

On newer devices without the Home button (as well as the iPhone 8 and 8 Plus), the S.O.S. mode is activated in exactly the same way as the power-off sequence. Users press and hold one of the volume buttons and the side button. The power off/emergency screen appears.

On older devices, the S.O.S. mode is activated by rapidly pressing the side (or top) button five times. The Emergency SOS slider will appear. Users in India only need to press the button three times, after which the iPhone automatically makes an emergency call.

“If you use the Emergency SOS shortcut, you need to enter your passcode to re-enable Touch ID, even if you don’t complete a call to emergency services.” (Source: Use Emergency SOS on your iPhone)

How to exit S.O.S. mode

To exit the S.O.S. mode, users tap on the “Cancel” icon. The device will prompt for the passcode (biometric identification methods are disabled). Alternatively, one can slide the Power off slider to the right to switch off the device.

Forensic implications of S.O.S. mode

Once invoked, the S.O.S. mode has the following forensic implications.

  • All biometric authentication methods (Touch ID and Face ID) are disabled. The device must be unlocked with a passcode.
  • Data transmission on USB port is switched off (USB restricted mode is immediately activated). This makes traditional acquisition efforts fruitless, potentially affecting passcode recovery solutions offered by companies such as Cellebrite and GrayShift.

TerraMaster is a relatively new company specializing in network attached storage and direct attached storage solutions. The majority of TerraMaster NAS solutions are ARM64 and Intel-based boxes aimed at the home and SOHO users. TerraMaster’s OS (TOS) is based on Linux. At this time, TOS 4.1 is the current version of the OS.

TerraMaster advertises secure AES encryption with unspecified key length through the entire range of its current NAS devices. This time around, we’re dealing with folder-based encryption that runs on top of the open-source encrypting file system eCryptfs. TerraMaster’s implementation of data encryption is extremely simplistic and lacks any sort of management for either the encryption key or the encrypted data.

Abstract and Summary

TerraMaster implements folder-based AES encryption with a single, fixed, unchangeable encryption key based on the user-provided password. The company does not specify the length of the key used for AES encryption. A 42-byte (336-bit) encryption key file can be manually exported for backup purposes. Users can unlock encrypted volumes by either typing the original plain-text password or uploading the encryption key.

TerraMaster has never documented any technical details about the underlying encryption mechanisms.

Encryption key: plain-text password or key file (must be manually exported while the encrypted share is mounted and unlocked).

The original password is used as Media Encryption Key. The concept of Key Encryption Keys is never utilized here; as a result, users cannot change their encryption password at all. In addition, TerraMaster OS does not have provisions for encrypting existing data or permanently decrypting encrypted shares. Any changes to encryption require deleting and re-creating shares and filling them up with data.

The entire encryption scheme lacks any sort of technical documentation.

Test Bench

We analyzed a TerraMaster F2-220 device based on a quad-code ARM64 design. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of TOS 4.1.

TerraMaster: Folder-Based Encryption

TerraMaster uses folder-based encryption based on eCryptfs, an open-source stacked cryptographic file system. Detailed information on eCryptfs is available here. This is the same encryption scheme as used in consumer Synology NAS devices. However, while Synology properly documents the restrictions of folder-based encryption, TerraMaster does not. As a result, the user finds out about the fact that encrypted file names are restricted to 143 Latin characters in a hard way by getting a write error when attempting to store a file with a name that is longer than permitted. Using Asian characters makes the possible file names even shorter.

From the point of view of a normal consumer, TerraMaster’s implementation of encryption is not just restrictive; it’s restrictive by surprise since no advance warning is given and no documentation is available about it.

Once the encrypted share is created, users cannot change the encryption passphrase.

Encrypting

Users can only encrypt newly created, empty shares. Encrypting an existing share is not possible. One must first delete the encrypted share, create a new one while selecting the encryption option. As a result, encrypting shares with existing data is not supported.

The good thing about this encryption scheme is the ability to create multiple shares, each with its own unique password. If there are multiple users, each user can encrypt their personal share with their own password. However, the complete inability to change the encryption password makes this approach dubious in the grand scheme of things.

Creating an encrypted share

The first step is creating a new share:

The “Encrypt this shared folder” box activates the encryption. The encryption feature requires a password, which is used as an encryption key. There are no obvious limitations (minimum or maximum) to the length of the password or supported character sets.

The process is concluded after setting access permissions and confirming settings:

The encrypted share is created and mounted. Note the “lock” icon:

Exporting the encryption key

Pretty much the only thing users can do with their encryption key other than using it for mounting shares is exporting it to a file.

In order to export the key, users must re-enter their encryption password:

Mounting encrypted shares

The encrypted volumes can be only mounted manually. Users must log in to the TOS Web UI, click on the encrypted share and use the Mount command. There are no auto-mount options available, and there are no vulnerabilities connected with the improper storage or handling of encryption keys.

The following two options are supported.

  1. Mounting with the original plain-text password.
  2. Mounting with the exported key file.

Choosing between these two options, the key file appears to be the more secure one as users can generate a long, random password with high volatility and use that password to produce the backup key file.

Unmounting encrypted shares

Encrypted shares are unmounted automatically once the NAS is powered off or rebooted. Manually unmounting the encrypted share requires accessing the Web UI:

Permanent decryption

Your familiar full-disk encryption tools such as Microsoft BitLocker allow removing the password from an encrypted volume. This is possible because these encryption tools use a concept of separate Media Encryption Keys (MEK, which are used to protect the data) and Key Encryption Keys (KEK, which are used to protect, or “wrap”, the MEK).

TerraMaster does not use the concept of separate MEK and KER. As a result, removing the password is not possible without physically decrypting the entire set of data (which is not supported by TOS). The only way to permanently decrypt the data is removing the encrypted share, re-creating the share without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary encryption keys that are used to encrypt and decrypt the data, and secrets that are used to unlock the encryption keys. This wonderful concept allows many things such as using any one of the several different passwords (or multiple types of authentication credentials, such as a smart card or a password) to unlock encrypted volumes. Sadly, this concept is rarely used by NAS manufacturers. TerraMaster is no exception; users cannot change the password because the password itself is the Media Encryption Key.

Manually Decrypting Encrypted Shares

Looking at the path that contains the encrypted files, I wonder if TerraMaster could be inspired by Synology’s implementation of folder-based encryption. The path to encrypted share looks as follows:

/mnt/md0/@encrypted@/

Where “encrypted” is the name of the share (as seen on screenshots above).

Path to decrypted files/mounted share:

/mnt/md0/encrypted/

Since TerraMaster uses eCryptfs, we can use the familiar command to mount the encrypted share:

mount -t ecryptfs /mnt/md0/@encrypted@ /mnt/md0/encrypted

You will need the user’s original, plain-text encryption password. TOS does not appear to be storing the encryption password or the encryption key file anywhere on the disk or in the boot DOM.

If you are able to decrypt the files, but the file names remain encrypted (ECRYPTFS_FNEK_ENCRYPTED), check out the following threads:

Alternatively, this open-source tool: pecryptfs – Portable Userspace eCryptfs may help decrypting individual file names.

What Risks Are Covered by TerraMaster Security Model

Similar to other implementations of NAS encryption, the security model employed by the TerraMaster is stripped down to the bare essentials. I have the following remarks about the TOS security model.

  1. Unlike volume encryption schemes, folder-based encryption comes with encryption metadata duplicated in every file. “eCryptfs stores cryptographic metadata in the header of each file, so that encrypted files can be copied between hosts; the file will be decrypted with the proper key in the Linux kernel keyring.” (source) This makes secure erase of encrypted data impossible. To securely erase data encrypted with eCryptfs, one must either wipe (overwrite) encryption metadata in each and every encrypted file; wipe the full content of every file; or wipe the entire disk.
  2. This encryption model does not properly protect the data if one needs to send the disk out for repair/replacement or simply wants to sell the disk. The encryption metadata is duplicated in every file in the encrypted folder. As a result, the attacker can obtain a single file and run a (fast) attack on the encryption key. Open-source tools such as pecryptfs – Portable Userspace eCryptfs may help decrypting individual files.
  3. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  4. The encryption key cannot be changed. Enough said.

Conclusion: TerraMaster Folder Encryption

When it comes to attached storage encryption, we are still in the Stone Age. The lack of basic features, many of which we accept as a given, makes TerraMaster encryption hardly usable. The lack of technical documentation, undocumented functional restrictions and encryption metadata duplicated in every file makes this encryption hardly useful. TerraMaster OS does not separate Media Encryption Keys and Key Encryption Keys, which makes password changes impossible.

The lack of the key management, the inability to change the encryption password, and the inability to encrypt or permanently decrypt existing shares makes TerraMaster NAS encryption one of the least flexible implementations, on par with Thecus NAS encryption. The protection system uses the well-established eCryptfs encryption framework, yet the TOS implementation still lacks transparency or any sort of technical documentation. Security wise, the data would be impossible to decrypt without knowing (or breaking) the user’s encryption password (or, alternatively, without access to the exported encryption key).

At the same time, TOS encryption implementation is straightforward enough to appeal to some users. However, those same users may be put off by the need of re-entering their encryption password in the Web interface every time they power on or reboot the NAS.

Thecus has been manufacturing NAS devices for more than 15 years. The company develops an in-house Linux-based NAS OS, the ThecusOS. At this time, the most current version of the OS is ThecusOS 7. Thecus advertises secure data encryption in most of its NAS devices. The company’s volume-based encryption tool allows users to fully encrypt their entire RAID volume, defending essential data in instances of theft of the physical device. We found Thecus’ implementation of encryption somewhat unique. In this research, we’ll verify the manufacturer’s claims and check just how secure is Thecus’ implementation of 256-bit AES encryption.

Abstract and Summary

Thecus uses volume-based 256-bit AES encryption with a single, fixed, unchangeable encryption key. The 3968-byte (31744-bit) encryption key file is generated at the time the user creates a new encrypted volume based on the user’s password (4-16 characters, 0-9, a-z, A-Z only). Creating several encrypted volumes with the same password produces different encryption key files.

The encryption key is stored on an external USB drive (the only, forced option) and does not have any additional protection.

The encrypted volume is automatically unlocked once the user inserts the USB drive that contains the correct encryption key.

The original password the user typed when creating an encrypted volume is never used again, anywhere. Users cannot change the encryption password. Users cannot encrypt existing data. Users cannot permanently decrypt encrypted volumes. Any changes to encryption require deleting and re-creating the volume and filling it up with data. The entire encryption scheme lacks any sort of technical documentation.

The entire protection scheme is completely undocumented. For example, it is not clear what the password is used for since the user never has to type it again (ever) to mount or otherwise access encrypted volumes.

Note: SED is supported by ThecusOS but was not tested in our lab.

Test Bench

We analyzed a Thecus N2810 device based on an Intel Celeron Processor N2810. A non-SED WD Red HDD was used to set up the NAS perform the analysis. The NAS was running on the latest available version of ThecusOS 7.

Volume-Based Encryption

ThecusOS supports volume-based encryption. Unlike folder-based encryption that allows protecting (or not protecting) individual shares, volume-based encryption protects the entire RAID volume. The closest analogy to volume-based encryption would be BitLocker in Microsoft Windows or FileVault 2 in Apple macOS. However, the Thecus implementation is significantly more basic compared to Apple’s or Microsoft’s full-disk encryption tools.

Encrypting

Users can only encrypt newly created, empty RAID volumes (regardless of the number of disks; a single-disk RAID volume can be encrypted just as easily as a volume spanning across multiple physical disks).

Encrypting an existing volume is not possible. One must first remove the volume, create a new one and tick the “Encrypt” box. As a result, encrypting volumes with existing data is not supported.

The first step is creating a new volume:

The optional encryption feature requires a password. The password must be 4 to 16 characters long; character groups 0-9, a-z, A-Z are supported (no special characters and no local characters).

Users don’t have to memorize that password as they’ll never have to type it again to access the encrypted data. Instead, ThecusOS will generate a 3968-byte (31744-bit) encryption key, and store that key on an external USB drive that must be connected to the NAS at the time the encrypted volume is created.

Once the user inserts an external USB drive (e.g. a flash drive) into one of the available USB ports, the NAS saves the encryption key on that drive and creates and mounts the encrypted volume.

Mounting encrypted volumes

The encrypted volumes are mounted automatically when the user inserts a USB drive that contains the volume encryption key into any available USB port on the Thecus NAS. There are no additional prompts, and there is no need to open the Web UI.

The following scenarios are supported.

  1. The NAS is powered on or rebooted; no USB drive containing the encryption key is inserted. In this case, the encrypted volume is locked, and the data is not accessible.
    However, the NAS can still complete the boot sequence as the main OS (and some configuration files) are stored on a small NAND storage chip and not on the hard drive(s).
  2. The NAS is powered on or rebooted; the USB drive containing the encryption key is inserted. In this case, the encrypted volume will be mounted by the time the device completes the boot sequence.
  3. The most interesting scenario is when the NAS is powered on or rebooted without a USB drive inserted, and the user inserts the USB drive containing the encryption key at a later point. In this case, the OS will automatically recognize the USB drive, read the encryption key and automatically mount the encrypted volume.

Locking encrypted volumes

As we figured, encrypted volumes are mounted automatically when the user inserts the correct USB drive. What happens after the USB drive is removed? In this case, the NAS keeps the encrypted volume mounted. The volume remains mounted until the NAS is powered off or rebooted, or until the user manually locks the volume through the Web UI.

Decrypting

If you are used to BitLocker, you probably know it is easily possible to remove the password from an encrypted volume. Interestingly, BitLocker will not decrypt any data that has already been encrypted; instead, it’ll just store the unwrapped encryption key in the volume header, allowing the system to pick up the key and access information without a password. Any new information saved on such BitLocker volumes would be saved unencrypted.

With Thecus, the situation is much simpler. Users cannot remove encryption or permanently decrypt encrypted volumes, period. The only way to permanently decrypt the data is removing the encrypted volume, re-creating the volume without encryption and filling it up with data.

Changing the password: impossible

Decades ago, manufacturers came up with a brilliant idea of separating the binary keys that are used to actually encrypt and decrypt the data, and user-provided secrets that are used to access the data. In symmetric cryptography, only one unique binary encryption key may be used to encrypt and decrypt the data; this is called the Media Encryption Key (or Data Encryption Key). However, users can unlock encrypted data by using multiple different types of credentials such as plain-text passwords, credentials stored on secure smart cards or TPM modules, binary keys (files) or combinations of thereof. These credentials (Key Encryption Keys) are used to encrypt (wrap) the Media Encryption Key. Multiple different Key Encryption Keys may be used to wrap the same Media Encryption Key, allowing the user to instantly change their plain-text password, add or remove smart cards and other credentials.

ThecusOS 7 does not use the concept of Key Encryption Keys. The user’s original plain-text password is used to produce a single, fixed Media Encryption Key. Neither the password nor the encryption key can be changed after the volume is encrypted.

Observations

While users are required to enter a password when encrypting the volume, this password will never be used again anywhere in the ThecusOS interface. I was unable to find any references to this password in the Thecus technical documentation or the online knowledge base. The password is not used to decrypt data or to mount encrypted partitions. Users will never have to type that password again. In other words, the password seems completely redundant in this setup. The lack of a proper explanation, let alone comprehensive technical documentation, makes me shake my head.

ThecusOS produces different encryption keys when creating volumes protected with the same password. This is a good hint that the password is salted with some random data. The lack of proper documentation makes this guess as good as any others.

Thecus and SED Encryption

ThecusOS supports SED (Self-Encrypting Drive) encryption, as seen on the screen shot below.

We have not tested the SED implementation due to the lack of a compatible hard drive. Considering the cost and market positioning of the Thecus N2810, the model is likely to be used with consumer-grade NAS hard drives such as the Western Digital Red or Seagate Ironwolf series, both of which lack the SED support.

What Risks Are Covered by Thecus Security Model

The security model employed by the ThecusOS is stripped down to the bare essentials. I have the following remarks about the Thecus security model.

  1. It is not clear why the system prompts for a password if that password cannot be used to unlock volumes and cannot be changed. If the user’s password is only needed as a random seed of a sort, this must be properly disclosed and documented.
  2. The lack of any sort of technical documentation for the data protection scheme is discouraging. This might be passable for the home user and occasional small office use, but unacceptable for anything beyond that.
  3. The encryption key is stored on a separate USB drive. Users can conveniently insert that USB drive at any time to automatically unlock encrypted volumes. As a result, the entire protection scheme is based exclusively on “something you have”. Anyone who has access to the USB drive holding the encryption key will be able to mount encrypted volumes.

As one can see, it all comes down to whether or not the attacker has access to the USB drive containing the encryption keys.

If the USB encryption key is stored separately of the NAS unit, and the NAS is powered off, the encrypted data is protected against the theft of the hard drives and the theft of the whole NAS unit.

If the attacker has access to both the NAS unit and the USB drive containing the encryption key, the protection is nil.

Conclusion: Thecus Encryption vs. Microsoft BitLocker

When it comes to full-disk encryption, Microsoft BitLocker and Apple FileVault 2 are the first things that come to mind, with TrueCrypt and VeraCrypt being the most popular third-party implementations. Secure encryption, comprehensive key management and multiple methods for encrypting and unlocking volumes are supported by all of these crypto-containers.

When it comes to attached storage encryption, you are welcome back to the Stone Age. A typical NAS advertising 256-bit AES encryption lacks any kind of key management; often to the point the user cannot even change their encryption password without deleting the entire volume, re-creating, re-encrypting and re-filling with data. Many NAS manufacturers have no idea about the existence of separate Media Encryption Keys and Key Encryption Keys, let alone their multiple instances. A typical NAS sold to a home or small office user does not allow encrypting existing data or removing the password from encrypted volumes should you no longer need to protect them.

All of these statements are true for the ThecusOS 7. The lack of even the basic key management, the inability to change the encryption password, and the inability to encrypt or decrypt existing volumes makes Thecus NAS encryption one of the least flexible ever. The protection system lack transparency or any sort of technical documentation. How does the system come up with a 3968-byte encryption key based on the user’s 4 to 16-character password? In a case of data loss, is it possible to decrypt the data with the user’s password instead of the encryption key? Does the key contain the user’s password, the hash of a password, or is it mostly random data? None of these questions have answers in the technical documentation.

At the same time, the encryption implementation is simple and straightforward. Based on a file stored on a removable USB drive, the data would be impossible to decrypt without said USB drive (unless a vulnerability is found). This encryption would likely be sufficient to protect most data stored by home and small office users.

Challenges in Computer and Mobile Forensics: What to Expect in 2020

The past two years introduced a number of challenges forensic experts have never faced before. In 2018, Apple made it more difficult for the police to safely transport a seized iPhone to the lab by locking the USB port with USB restricted mode, making data preservation a challenge. The release of the A12 platform, also in 2018, made it difficult to unlock iOS devices protected with an unknown password, while this year’s release of iOS 13 rendered unlock boxes useless on iPhones based on the two most recent platforms.

On desktop and especially laptop computers, the widespread use of SSD drives made it impossible to access deleted data due to trim and garbage collection mechanisms. The users’ vastly increased reliance on cloud services and mass migration off the forensically transparent SMS platform towards the use of end-to-end encrypted messaging apps made communications more difficult to intercept and analyze.

Sheer amounts of data are greater than ever, making users rely more on external (attached) storage compared to using internal hard drives. Many attached storage devices are using secure encryption, some of them without even prompting the user. Extracting data from such devices becomes a challenge, while analyzing the huge amounts of information now requires significantly more time and effort.

The number of online accounts used by an average consumer grows steadily year over year. While password reuse and the use of cloud services to store and synchronize passwords makes experts’ jobs easier, the spread of secure, encrypted password management services is turning into a new challenge.

Knowing everyday challenges in desktop and mobile forensics, we can now peek into the future. (more…)

Skype synchronizes chats, text messages and files sent and received with the Microsoft Account backend. Accessing Skype conversation histories by performing a forensic analysis of the user’s Microsoft Account is often the fastest and easiest way to obtain valuable evidence. Learn how to use Elcomsoft Phone Breaker to quickly extract the complete conversation histories along with attachments and metadata from the user’s Microsoft Account.

What’s It All About?

With over 1.55 billion accounts and more than 420 million daily users, Skype is one of the world’s biggest instant messaging apps. While there is no lack of competition in the highly crowded market of instant messaging apps, Skype maintains its user base. This feature-rich app is available for all relevant platforms, and is actively developed and frequently updated by Microsoft. Skype is secure (enough) while maintaining transparency to the law enforcement, which makes Skype the only allowed VoIP communication app in countries such as the UAE. The free Skype-to-phone calls included with all Microsoft Office 365 subscriptions help Skype gain popularity among corporate and small office users, while integration with Alexa and Cortana voice assistants makes Skype the tool of choice for voice calls.

(more…)