Using KitKat verified boot

Android 4.4 introduced a number of security enhancements, most notably SELinux in enforcing mode. One security feature that initially got some press attention, because it was presumably aiming to ‘end all custom firmware’, but hasn’t been described in much detail, is verified boot. This post will briefly explain how verified boot works and then show how to configure and enable it on a Nexus device.

Verified boot with dm-verity

Android’s verified boot implementation is based on the dm-verity device-mapper block integrity checking target. Device-mapper is a Linux kernel framework that provides a generic way to implement virtual block devices. It is used to implement volume management (LVM), full-disk encryption (dm-crypt), RAIDs and even distributed replicated storage (DRBD). Device-mapper works by essentially mapping a virtual block device to one or more physical block devices, optionally modifying transferred data in transit. For example, dm-crypt decrypts read physical blocks and encrypts written blocks before committing them to disk. Thus disk encryption is transparent to users of the virtual dm-crypt block device. Device-mapper targets can be stacked on top of each other, making it possible to implement complex data transformations. 
As we mentioned, dm-verity is a block integrity checking target. What this means is that it transparently verifies the integrity of each device block as it is being read from disk. If the block checks out, the read succeeds, and if not — the read generates an I/O error as if the block was physically corrupt. Under the hood dm-verity is implemented using a pre-calculated hash tree which includes the hashes of all device blocks. The leaf nodes of the tree include hashes of physical device blocks, while intermediate nodes are hashes of their child nodes (hashes of hashes). The root node is called the root hash and is based on all hashes in lower levels (see figure below). Thus a change even in a single device block will result in a change of the root hash. Therefore in order to verify a hash tree we only need to verify its root hash. At runtime dm-verity calculates the hash of each block when it is read and verifies it using the pre-calculated hash tree. Since reading data from a physical device is already a time consuming operation, the latency added by hashing and verification as relatively low.

[Image from Android dm-verity documentation,  licensed under Creative Commons Attribution 2.5]

Because dm-verity depends on a pre-calculated hash tree over all blocks of a device, the underlying device needs to be mounted read-only for verification to be possible. Most filesystems record mount times in their superblock or similar metadata, so even if no files are changed at runtime, block integrity checks will fail if the underlying block device is mounted read-write. This can be seen as a limitation, but it works well for devices or partitions that hold system files, which are only changed by OS updates. Any other change indicates either OS or disk corruption, or a malicious program that is trying to modify the OS or masquerade as a system file. dm-verity’s read-only requirement also fits well with Android’s security model, which only hosts application data on a read-write partition, and keeps OS files on the read-only system partition.

Android implementation

dm-verity was originally developed in order to implement verified boot in Chrome OS, and was integrated into the Linux kernel in version 3.4. It is enabled with the CONFIG_DM_VERITY kernel configuration item. Like Chrome OS, Android 4.4 also uses the kernel’s dm-verity target, but the cryptographic verification of the root hash and mounting of verified partitions are implemented differently from Chrome OS.

The RSA public key used for verification is embedded in the boot partition under the verity_key filename and is used to verify the dm-verity mapping table. This mapping table holds the locations of the target device and the offset of the hash table, as well as the root hash and salt. The mapping table and its signature are part of the verity metablock which is written to disk directly after the last filesystem block of the target device. A partition is marked as verifiable by adding the verify flag to the Android-specific fs_mgr flags filed of the device’s fstab file. When Android’s filesystem manager encounters the verify flag in fstab, it loads the verity metadata from the block device specified in fstab and verifies its signature using the verity_key. If the signature check succeeds, the filesystem manager parses the dm-verity mapping table and passes it to the Linux device-mapper, which use the information contained in the mapping table in order to create a virtual dm-verity block device. This virtual block device is then mounted at the mount point specified in fstab in place of the corresponding physical device. As a result, all reads from the underlying physical device are transparently verified against the pre-generated hash tree. Modifying or adding files, or even remounting the partition in read-write mode, results in an integrity verification failure and an I/O error.

We must note that as dm-verity is a kernel feature, in order for the integrity protection it provides to be effective, the kernel the device boots needs to be trusted. On Android, this means verifying the boot partition, which also includes the root filesystem RAM disk (initrd) and the verity public key. This process is device-specific and is typically implemented in the device bootloader, usually by using an unmodifiable verification key stored in hardware to verify the boot partition’s signature.

Enabling verified boot

The official documentation describes the steps required to enable verified boot on Android, but lacks concrete information about the actual tools and commands that are needed. In this section we show the commands required to create and sign a dm-verity hash table and demonstrate how to configure an Android device to use it. Here is a summary of the required steps: 
  1. Generate a hash tree for that system partition.
  2. Build a dm-verity table for that hash tree.
  3. Sign that dm-verity table to produce a table signature.
  4. Bundle the table signature and dm-verity table into verity metadata.
  5. Write the verity metadata and the hash tree to the system parition.
  6. Enable verified boot in the devices’s fstab file.
As we mentioned earlier, dm-verity can only be used with a device or partition that is mounted read-only at runtime, such as Android’s system partition. While verified boot can be applied to other read-only partition’s such as those hosting proprietary firmware blobs, this example uses the system partition, as protecting OS files results in considerable device security benefits. 
A dm-verity hash tree is generated with the dedicated veritysetup program. veritysetup can operate directly on block devices or use filesystem images and write the hash table to a file. It is supposed to produce platform-independent output, but hash tables produced on desktop Linux didn’t quite agree with Android, so for this example we’ll generate the hash tree directly on the device. To do this we first need to compile veritysetup for Android. A project that generates a statically linked veritysetup binary is provided on Github. It uses the OpenSSL backend for hash calculations and has only been slightly modified (in a not too portable way…), to allow for the different size of the off_t data type, which is 32-bit in current versions of Android’s bionic library. 
In order to add the hash tree directly to the system partition, we first need to make sure that there is enough space to hold the hash tree and the verity metadata block (32k) after the last filesystem block. As most devices typically use the whole system partition, you may need to modify the BOARD_SYSTEMIMAGE_PARTITION_SIZE value in your device’s BoardConfig.mk to allow for storing verity data. After you have adjusted the size of the system partition, transfer the veritysetup binary to the cache or data partitions of the device, and boot a recovery that allows root shell access over ADB. To generate and write the hash tree to the device we use the veritysetup format command as shown below.

# veritysetup --debug --hash-offset 838893568 --data-blocks 204800 format 
/dev/block/mmcblk0p21 /dev/block/mmcblk0p21
...
# Updating VERITY header of size 512 on device /dev/block/mmcblk0p21, offset 838893568.
VERITY header information for /dev/block/mmcblk0p21
UUID: 0dd970aa-3150-4c68-abcd-0b8286e6000
Hash type: 1
Data blocks: 204800
Data block size: 4096
Hash block size: 4096
Hash algorithm: sha256
Salt: 1f951588516c7e3eec3ba10796aa17935c0c917475f8992353ef2ba5c3f47bcb
Root hash: 5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1

This example was executed on a Nexus 4, make sure you use the correct block device for your phone instead of /dev/block/mmcblk0p21. The –hash-offset parameter is needed because we are writing the hash tree to the same device that holds filesystem data. It is specified in bytes (not blocks) and needs to point to a location after the verity metadata block. Adjust according to your filesystem size so that hash_offset > filesystem_size + 32k. The next parameter, –data-blocks, specifies the number of blocks used by the filesystem. The default block size is 4096, but you can specify a different size using the –data-block-size parameter. This value needs to match the size allocated to the filesystem with BOARD_SYSTEMIMAGE_PARTITION_SIZE. If the command succeeds it will output the calculated root hash and the salt value used, as shown above. Everything but the root hash is saved in the superblock (first block) of the hash table. Make sure you save the root hash, as it is required to complete the verity setup.

Once you have the root hash and salt, you can generate and sign the dm-verity table. The table is a single line that contains the name of the block device, block sizes, offsets, salt and root hash values. You can use the gentable.py script (edit constant values accordingly first) to generate it or write it manually based on the output of veritysetup. See dm-verity’s documentation for details about the format. For our example it looks like this (single line, split for readability):

1 /dev/block/mmcblk0p21 /dev/block/mmcblk0p21 4096 4096 204800 204809 sha256 
5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1
1f951588516c7e3eec3ba10796aa17935c0c917475f8992353ef2ba5c3f47bcb

Next, generate a 2048-bit RSA key and sign the table using OpenSSL. You can use the command bellow or the sign.sh script on Github.

$ openssl dgst -sha1 -sign verity-key.pem -out table.sig table.bin

Once you have a signature you can generate the verity metadata block, which includes a magic number (0xb001b001) and the metadata format version, followed by the RSA PKCS#1.5 signature blob and table string, padded with zeros to 32k. You can generate the metadata block with the mkverity.py script by passing the signature and table files like this:

$ ./mkverity.py table.sig table.bin verity.bin

Next, write the generated verity.bin file to the system partition using dd  or a similar tool, right after the last filesystem block and before the start of the verity hash table. Using the same number of data blocks passed to veritysetup, the needed command (which also needs to be executed in recovery) becomes:

# dd if=verity.bin of=/dev/block/mmcblk0p21 bs=4096 seek=204800

Finally, you can check that the partition is properly formatted using the veritysetup verify command as shown below, where the last parameter is the root hash:

# veritysetup --debug --hash-offset 838893568 --data-blocks 204800 verify 
/dev/block/mmcblk0p21 /dev/block/mmcblk0p21
5f061f591b51bf541ab9d89652ec543ba253f2ed9c8521ac61f1208267c3bfb1

If verification succeeds, reboot the device and verify that the device boots without errors. If it does, you can proceed to the next step: add the verification key to the boot image and enable automatic integrity verification.

The RSA public key used for verification needs to be in mincrypt format (also used by the stock recovery when verifying OTA file signatures), which is a serialization of mincrypt’s RSAPublicKey structure. The interesting thing about this structure is that ts doesn’t simply include the modulus and public exponent values, but contains pre-computed values used by mincrypt’s RSA implementation (based on Montgomery reduction). Therefore converting an OpenSSL RSA public key to mincrypt format requires some modular operations and is not simply a binary format conversion. You can convert the PEM key using the pem2mincrypt tool (conversion code shamelessly stolen from secure adb‘s implementation). Once you have converted the key, include it in the root of your boot image under the verity_key filename. The last step is to modify the device’s fstab file in order to enable block integrity verification for the system partition. This is simply a matter of adding the verify flag, as shown below:

/dev/block/platform/msm_sdcc.1/by-name/system  /system  ext4  ro, barrier=1  wait,verify

Next, verify that your kernel configuration enable CONFIG_DM_VERITY, enable it if needed and build your boot image. Once you have boot.img, you can try booting the device with it using fastboot boot boot.img (without flashing it). If the hash table and verity metadata blcok have been generated and written correctly, the device should boot, and /system should be a mount of the automatically created device-mapper virtual device, as shown below. If the boot is successful, you can permanently flash the boot image to the device.

# mount|grep system
/dev/block/dm-0 /system ext4 ro,seclabel,relatime,data=ordered 0 0

Now any modifications to the system partition will result in read errors when reading the corresponding file(s). Unfortunately, system modifications by file-based OTA updates, which modify file blocks without updating verity metadata, will also invalidate the hash tree. As mentioned in the official documentation, in order to be compatible with dm-verity verified boot, OTA updates should also operate at the block level, ensuring that both file blocks and the hash tree and metadata are updated. This requires changing the current OTA update infrastructure, which is probably one of the reasons verified boot hasn’t been deployed to production devices yet.

Summary

Android includes a verified boot implementation based on the dm-verity device-mapper target since version 4.4. dm-verity is enabled by adding a hash table and a signed metadata block to the system partition and specifying the verify flag in the device’s fstab file. At boot time Android verifies the metadata signature and uses the included device-mapper table to create and mount a virtual block device at /system. As a result, all reads from /system are verified against the dm-verity hash tree, and any modification to the system partition results in I/O errors. 

4G: Ten Times the Speed with Twice the Risk?

Time and chance overtakes us all, especially when it comes to technology. But the latest and greatest iterations aren’t always a steady stream of improvements on both ends, and can sometimes create new issues in the place of old ones.

This situation rings true when it comes to mobile phones. Ten years ago, consumers could safely place a call—albeit a slower one with less reception coverage—without worrying about putting their identity at risk. Today, consumers are likely checking Facebook, watching a video and surfing the web, in addition to making calls on improved networks. However, broadcasting information over a network using the same communication standards as the Internet may come at a price. That’s right, 4G uses the World Wide Web to transmit data, giving hackers more opportunities to intercept sensitive information.

4G is an important evolution providing amazing bandwidth enabling mobile users to stream music, videos and movies at a much faster rate than ever before. 4G is a generic industry term describing the fourth generation of mobile technology that gets your phone to talk to cell towers and, eventually, another device. Some companies also refer to 4G as LTE, or Long Term Evolution. 4G networks are able to provide better service over their 3G counterparts by using an Internet-based connection—the same as your home computer—that allows consumers to text, call, and video message faster from a mobile device.

However, along with the multitude of usability benefits offered by 4G enabled connections, this communication standard may not actually be as secure as past versions. The standard in question, Internet Protocol (IP), sends information through a network’s IP address, which is the equivalent of a postal address for websites on the backend. Hackers can easily exploit this communication standard, with the most immediate attack used over 4G networks being a “Man-in-the Middle” (MITM) attack —where a hacker impersonates, to your device or to you, a particular user or service in order to collect sensitive data before sending it on to its final destination.

A MITM attack can also trick users into installing malware—malicious software capable of tracking data, controlling devices and intercepting text messages—on a phone. In fact, this very scenario played out at a major security conference in 2011, where some attendees downloaded a supposed software update for their phones that turned out to be a malware package. The malware in question gave the hacker near universal access to victims’ texts messages, usernames and passwords.

So how can you protect your information over a 4G connection? While this is mostly a technical problem that network providers are working to solve on their end, there are a few strategies to help protect you and your device in the meantime.

  • Be wary of unsolicited updates. The 2011 security conference attendees learned the hard way that hackers can disguise malware as seemingly safe software updates. Don’t make the same mistake: never download an update to your device that doesn’t come from a major app store like Google Play or the Apple App Store.
  • Watch your text messages for suspicious links. Another way hackers use to trick device owners into clicking on a malicious link is text messages. Such links can send users to websites designed to exploit mobile devices. If an unsolicited text message is sent to you with a suspicious link, always ignore it—or better yet, delete it.
  • Install McAfee® Mobile Security. McAfee Mobile Security is our free app for both Android and iOS devices. The Android app includes malware protection, a messaging filter that blocks malicious texts, web-protection, that warns you if you visit a malicious site, any many more features to protect your privacy.

McAfee Mobile Security is simple to use and promises maximum protection for all of your personal data. For more information about this product visit us online. For the latest updates on consumer threats and mobile security, follow us on Twitter at @McAfeeConsumer and on Facebook and tell us what you think!

lianne-caetano

The post 4G: Ten Times the Speed with Twice the Risk? appeared first on McAfee Blogs.

Change Your Password. World Password Day is 7 May!

We also say we want to be safe online. Yet sometimes our actions betray our words—especially if we’re using simple, short passwords for our online sites. Passwords with less than eight characters are the easiest to crack, especially if they include a proper noun or a word that’s in a dictionary. Hackers especially love passwords of all one character. Lose the “ilovedogs” password please.

Take a look at your passwords. Are they simple and include an actual word, or are they long and unique?  May 7th is World Password Day. Mark this day on your calendar, then do it: Take the pledge and change your passwords.

WorldPasswordDay

And don’t balk about changing your passwords; you must change them to be safe online. Your password is your first line of defense—not only for your online accounts, but also on your devices. Be like Nike and “Just Do It!” Think about this if you’re reluctant to change them:

  •  Research shows that 90% of passwords are vulnerable to hacking
  • The most common password is “123456”  and the second most common password, is “password”
  • 1 in 5 Internet users have had their email or social networking account compromised or taken over without their permission

 

Now, believe it or not, a password of eight characters, even with various symbols and no dictionary words, can be cracked. However, a password the length of “Earthquake in the Sahara” would take over a million years to unearth. Ladies and gents, size does matter when it comes to passwords.

Ditch your old passwords

They may already be on the black market, and if not, it’s inevitable. Especially in this post Heartbleed time, we need to make sure we all change our passwords.

Think pass-sentence, not password

Just four words (with spaces) will make a killer password. Toss in punctuation. Create a sentence that makes no sense, like “Sharks swimming in the shower” and then add some space, numbers and special characters so it’s “Sh@rks swimming >n The Sh0wer!” That’s a 30-word password, technically known as a passphrase, and beats out #8xq3@2P. And which is easier to remember?

And don’t use something that a person who knows you might be able to guess: If you own five black cats, don’t make a passphrase of “I love black cats.”

Here’s a fun way to make a passphrase.

WPD - How To Make A Stronger Password

Make the change

Now that you have a passphrase that will take millions of years to crack, it’s time to make use of it. Sift through all of your accounts and change your passwords, using a different passphrase for each account, and not similar, either, for optimal uncrackability.

Once all of your new passwords (passphrases) are in place, you’ll have peace of mind, knowing that it would take millions of years for these passwords to be cracked.

Remember, there’s no better time than World Password Day to change your password!

 

RobertSiciliano

Robert Siciliano is an Online Security Expert to McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!  Disclosures.

The post Change Your Password. World Password Day is 7 May! appeared first on McAfee Blogs.

‘Google’ Apps for Sports Betting Target Korean Users

Online scammers are always seeking to trick victims into paying money. Sports betting is a common lure for online scams to attract those who enjoy the thrill of gambling on sports. Usually these scammers use email or SMS messages to invite careless victims to such services. McAfee Labs has recently found many suspicious Android apps on Google Play that try to trick Korean users into registering on the scam websites. The apps claim to be part of a Google-powered service, but this is just a lie, of course.

scambet-1
Figure 1: Examples of the sports betting scam apps found on Google Play.

After launch, the app shows a login screen with a Google logo that claims to be “Google Sports Betting,” which is certainly not provided by Google. A user can “sign up” with the service by providing username, password, nickname, mobile phone number, email address, bank name, bank account number, and so on. The site has a page for users to pay to use its betting feature, but there is no description about the site owner or operating company on the site. Would a legitimate sports betting service disguise itself as a Google service? There’s no doubt that this is a scam site.

scambet-2
Figure 2: The scam service’s login screen and main screen of the app.

To our surprise, the bold app developer illegally employs the Google logo and copyright notice on the description page on Google Play. This step easily suggests a malicious scam app at first glance.

scambet-3
Figure 3: The scam uses screens with the Google logo and copyright notice.

In our investigation, we found some apps disguised as a Google service and others not, but they all share almost identical application code and website structure. The apps simply load the existing scam sites, which are hosted on the same or other servers. The scammers also offer sites to trap desktop PC users. Thus the potential victims are not limited to Android users, but also include users of PCs and other mobile devices.

spambet-5
scambet-4
Figure 4: The PC version of the scam sites disguised as”Google Sports Betting.”

We have discovered more than 30 apps of this kind on Google Play. The total download count stands between 13,000 and 45,000. We have also found many other sites hosting similar services with almost the same site structure, under the same or different server domains.

The actual damage depends on how users spend their time and money on these services, but at the least the scammers get personal information such as mobile phone number and perhaps email address, bank name, and bank account number. Some careless users might have also provided their Google account usernames and passwords on the service’s Google “login screen.” Any login attempt to the real Google account fails, but the information can be stored on the malicious service.

Sports fans, especially those who are looking forward to the upcoming FIFA World Cup in June, should be careful about this kind of sports betting scam. Don’t believe that Google will offer such a fantastic gambling experience for you.

McAfee Mobile Security detects these suspicious apps as Android/ScamBet.A, and also blocks browser access to the related sites.

The post ‘Google’ Apps for Sports Betting Target Korean Users appeared first on McAfee Blogs.