Hugo Barra on why Xiaomi is against microSD cards in phones

If you were to compare iOS and Android, the latter’s storage expansion option via microSD — up to a whopping 200GB these days — is often regarded as an advantage, though not all devices come with such offer. For instance, while HTC and LG have made the microSD slot a standard feature on their recent flagship devices, Samsung oddly decided to remove it from its Galaxy S6 series (ironically, the company has just announced new microSD cards). Xiaomi, on the other hand, seems to be on the fence: its flagship line has long ditched the microSD slot after its first-gen device, yet its affordable Redmi line uses said feature as a selling point. It’s as if Xiaomi is contradicting itself, but Hugo Barra, the company’s Vice President of International, gave us a more definitive answer after launching the Mi 4i in Hong Kong.

Xiaomi’s Hugo Barra shows off the Mi 4i’s small logic board.

“For high performance devices, we are fundamentally against an SD card slot.”

Barra backed up his statement by pointing out that his team didn’t want to sacrifice battery capacity, ergonomics, appearance and, in the case of the new Mi 4i, the second Micro SIM slot for the sake of letting users add a storage card. More importantly, microSD cards “are incredibly prone to failure and malfunctioning of various different sorts,” and the fact that there are a lot of fake cards out there — and we’ve seen it ourselves — doesn’t help, either.

“You think you’re buying like a Kingston or a SanDisk but you’re actually not, and they’re extremely poor quality, they’re slow, they sometimes just stop working, and it gives people huge number of issues, apps crashing all the time, users losing data, a lot of basically complaints and customer frustration. It’s gonna be a while before you finally accept that maybe the reason why it’s not performing is because you put in an SD card, right? You’re gonna blame the phone, you’re gonna blame the manufacturer, you’re gonna shout and scream and try to get it fixed, so many different ways until you say, ‘Actually, let me just take the SD card out and see what happens.’”

“It is a trend: SD cards will disappear.”

Barra probably would have given the same reasoning if he was still the VP of Google’s Android division. Despite many techies’ desire to have storage expansion option, all Google Nexus devices bar the Nexus One lack microSD expansion, and Matias Duarte, VP of design, once explained that this is because “in reality it’s just confusing for users.” Google engineer Dan Morrill also voiced a similar concern on Reddit a while back.

“It is a trend: SD cards will disappear,” Barra added. “You should basically not expect SD card slots in any of our flagships.

A disassembled Mi 4i displayed at the Hong Kong launch event.

On a similar note, Xiaomi’s flagship line has also long ditched the removable battery. Barra said his company’s sales data indicate a low demand for spare batteries and external battery chargers these days. Of course, there’s no doubt that this has to do with Xiaomi offering very cheap USB power banks (the 16,000 mAh version costs just around $18 in China), and these inadvertently help users transition from the days of removable batteries to fixed batteries. That said, Xiaomi’s Redmi phones still offer removable batteries along with a microSD slot — the latter a necessity as these dirt cheap devices come with relatively little internal storage space, which is typically just 8GB.

“Our thinking is if you’re gonna have a removable back for the purposes of having an SD slot, you might as well make the battery removable,” the exec explained. “It doesn’t really increase the cost of the battery that much.”

Xiaomi’s Brazil launch is happening in just a matter of weeks.

After yesterday’s Hong Kong event, Barra had already rushed back to Beijing for the Mi Note Pro launch earlier today, and then he’ll be off to Taiwan for another regional Mi 4i launch tomorrow. But what’s really keeping this exec busy is the preparation for Xiaomi’s entry into his home country, Brazil, which is a notoriously tough market for foreign electronics brands to crack due to local policies — you must either manufacture locally or pay heavy import taxes. Barra said that’s not an issue as Xiaomi already has local manufacturing partners (namely Foxconn), and he hinted that the launch is happening in just a matter of weeks. If all goes well, this will be Xiaomi’s ninth market globally, and also the first outside of Asia.

Filed under: Cellphones, Mobile

Comments

How to hide your API Key in Android

Many Android apps that interact with the cloud use a client – server architecture with the phone acting as a client and much of the heavy lifting taking place on the server. Sometimes you have control over the server, and sometimes it’s a third party who provides the data, e.g. traffic updates, stock market data, or weather information etc. Typically these third party providers use an API key as a simple authentication mechanism to grant access to these resources, and as a way to charge for their data.

Now there are lots of reasons why you might want to keep your API key safe. Obviously if you’re being charged for access to the API data then you don’t want someone to decompile your APK, find your API key, and then start using it in their own apps. It’s either going to cost you money for these stolen API calls, or worse still, create frustration for your existing users if your API suddenly stops working because the provider stops your access when it spots the increased activity. If your API key does become compromised then getting a new key out to your users is never easy. Do you revoke the old API key and switch to a new API key, potentially leaving users of earlier versions stranded? Or do you keep the old API key alive while you wait for the old users to upgrade, but run the risk of further bogus charges? Either way is not going to be 100% satisfactory, so it is best to avoid the situation completely.

Before we look at the options for hiding your API key, let’s look at how someone can find your API key. There are two basic types of attack, firstly by decompiling the APK to see if it is stored somewhere in the code, and secondly using a Man in the Middle (MITM) attack to see if it’s transmitted insecurely  over the web. To access the network traffic the hacker needs to root their phone using something like ProxyDroid. This allows the traffic to be intercepted using the Charles Proxy tool or BurpSuite using a MITM attack.

API keys are often sent via a URL. For example, you can make a request to the Weather Underground API using the following URL,
http://api.wunderground.com/api/2ee858dd063ef50e/conditions/q/MI/Troy.json where 2ee858dd063ef50e is the API key. If you send the request via HTTP then the API key would be clearly visible to anyone doing a MITM attack. Sending it correctly via HTTPS will make it impossible to see the API key via proxying. Note I used the word “correctly”. The media is littered with examples of MITM attacks where the HTTPS was intercepted because the app accepted a fake SSL cert generated by tools like Charles Proxy rather than checking that it came from a reputable Certificate Authority (CA). We’ve also found examples where the device itself didn’t handle certs correctly and any HTTPS traffic was open to a MITM attack. You also need to be careful about where the API key lives before you assemble the HTTPS call. We’ll look at that next.

In my audits of hundreds of Android mobile apps I have seen many attempts to hide the API key. In this article we look at some of the ways developers have tried to protect your API key.

The possible options are as follows:

1. In shared preferences, assets or resources folders
2. Hardcoded in Java
3. Using the NDK
4. API key Public/private key exchange

In shared preferences, assets or resources folders

Below is an example of an API key that was found by unzipping the APK file after it was pulled off the phone and looking in the asssets folder.

0M5WrSiVVUbMohPNDsrAmIb0hR6NftlV9E1hjvA
0M5WrSiVVUbMohPNDsrAmIb0hR6NftlV9E1hjvA
03JOvW5GGOOkIY0n70rIiPPFlZjqOqI3SFhKoYA

The most common place I find that developers store API keys is in the shared preferences, below is a an example. It’s common practice to put APIkeys in the resources folder in the APK, which then gets stored in shared preferences after the app is first opened.

<map>IO42DUS7M4C2
IO42DUS7M4C2
</map>


Hardcoded in Java

An API key is much much more likely to be found in the assets or resources folder than in the decompiled code because it’s much easier to update xml than compiled code. But it still happens regularly. Below an example of an API key found in a pharmacy app that was stored in a Constants.java file.

package com.riis.pharmacy;

public class Constants 
     public static final String API_TOKEN = "Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2BAY163ManCAb";

Using the NDK

The Android Native Devlopment Kit (NDK) allows you to write code in C/C++, and can be very useful when you’re trying to hide things like API keys. The good news is that NDK libraries can’t be decompiled making the information harder to find. The NDK compiled code can still be opened with a hexidecimal editor but by the nature of the API key they are harder to pick out in a hexidecimal editor.

#include
#include

jstring Java _ com _ riis _ apindk _ MainActivity _ invokeNativeFunction(JNIEnv* env, jobject javaThis) 
    return (*env)->NewStringUTF(env, "Nti4kWY-qRHTYq3dsbeip0P1tbGCzs2BAY163ManCAb");

You should include a call to see if the checksum matches your APK as otherwise someone can call your NDK library outside of your app to recover the password. This approach is ultimately not going to be good enough to stop someone from reading the binary. But it is a better option to consider if you have no other choice than to put the API or encryption keys on the device, for example if the backend server belongs to a third party provider. Disassembled code also rapidly becomes more difficult to understand as it gets further away from these simple helloworld examples.

Public/private API key exchange

While HTTPS securely hides the API key during transmission, retrieving the API key from the phone so the HTTPS call can be made is a real problem for developers. As we’ve seen hiding an API key is not dissimilar to how people try to hide an symmetric encryption key (see my earlier article on where to store your passwords). All these keys can be recovered using the adb backup or adb pull command and a little perseverance. So even if the hacker can’t perform a Man in the Middle attack they can still see how the call is put together and the API that’s used in the call so they can hijack your resource if it’s useful to them. We could try try to encrypt the API key on the phone but if you’re storing the encryption key on the phone, then you’re simply adding one extra step to get to the API key.

However you can use a public/private API key exchange to safeguard the API key, so it can no longer be stolen. The downside to using public/private key exchange for passwords is that the phone can’t be in airplane mode when you login as the decryption takes place on a remote server. That doesn’t apply to API keys as they’re always using network communication.

The key should first be encrypted with the public key on a remote server using your favorite library such as Google’s Keyczar. You can either store it in the res/xml folder so you can retrieve it when someone opens the app on the phone and then store it in the app’s shared preferences, or send it to the app from the remote server so it can be reused when needed. When the URL call is made the encrypted API key is sent via HTTPS and then decrypted on the server so it can be compared to the real API key. You can also use some other dynamic piece of information such as the username to make sure the encypted API key can’t itself be used as an API key. There is nothing to stop someone else from sending the same encrypted API key from a different app to defeat your efforts. You can stop these replay attacks by encrypting your API key together with a one-time only randomly generated number or GUID, known as a nonce. The nonce and API key are sent to the server for API authentication, and the API key and a new nonce are sent back to the client to be saved in the shared preferences after each login for the next use. Every generated nonce is saved when created and marked as used once it has been sent from any client.

Conclusion

What option you choose is probably going to be determined by how much control you have over the backend server. If you don’t have any control then you’re probably going to have to hide the API key using the NDK. If you do then we recommend the Public/Private encryption of the API key using nonces to prevent any replay attacks. In the next article we’ll look at the security implications of supporting earlier Android OS versions, as well as how some Android phones are more secure than others.

Subscribe to our Android Developer Newsletter
Join our Android Developers newsletter to get all the top developer news, tips & links once a week in your inbox
Email:

About the author

Godfrey Nolan is the founder and president of the mobile and web development company RIIS LLC based in Troy, Michigan, and Belfast, Northern Ireland.He has had a healthy obsession with reverse engineering bytecode. See more from him here. He’s also the author of Bulletproof Android: Practical Advice for Building Secure Apps.

Snapchat adds sharing tools to its news discovery portal

Snapchat’s curated selection of news stories called Discover is reportedly in trouble, with traffic dropping significantly since its debut back in January. That’s probably why the company has introduced a new function that lets you share articles and videos straight from the portal to your friends. Whenever you find something worth showing to other people, just press the screen and wait for the new tools to pop out. You can type a caption and/or write on the snapshot of the page with a digital marker, then you can send it out to pals you choose as you would any other “snap.” In addition to Discover’s new sharing function, you can now also take zoomed in videos by dragging your finger across the screen while recording. We took Discover’s new tools for a spin and embedded some samples below the fold, but you can try them out yourself after downloading the latest app refresh from iTunes or Google Play.

Filed under: Cellphones, Mobile

Comments

Source: Google Play, iTunes

Researchers find new ‘most distant’ galaxy in the universe

Peering through the voids of space is a lot like time travelling: the deeper we gaze into a seemingly endless Universe, the further back in time we can see. Now, a team of researchers led by astronomers from Yale University and UC Santa Cruz have announced that they’ve discovered the most distant galaxy to date. In fact, the galaxy, known a EGS-zs8-1, is so ludicrously far from Earth that light just now reaching us from it is about 13 billion years old. To put that in perspective, the Universe itself is 13.8 billion years. That means this galaxy began forming stars when the Universe was only 5 percent of its current age — barely 670 million years after big banging into existence.

“It [EGS-zs8-1] has already built more than 15% of the mass of our own Milky Way today,” Yale astronomer Pascal Oesch said in a statement. “But it had only 670 million years to do so. The universe was still very young then.” Astrophysical Journal Letters published the team’s research on May 5. Astronomers first noticed EGS-zs8-1 using the Hubble Space Telescope and then confirmed with the MOSFIRE instrument on the W.M. Keck Observatory’s 10-meter telescope. Though identification wasn’t too difficult given that the galaxy is among the brightest objects in the early universe.

Researchers plan to further study the galaxy — and how it helped shape the early Universe — once the James Webb telescope is launched in 2018. “Our current observations indicate that it will be very easy to measure accurate distances to these distant galaxies in the future with the James Webb Space Telescope,” co-author Garth Illingworth of the University of California-Santa Cruz said in a statement. “The result of JWST’s upcoming measurements will provide a much more complete picture of the formation of galaxies at the cosmic dawn.”

[Image Credit: NASA, ESA, P. Oesch and I. Momcheva (Yale University), and the 3D-HST and HUDF09/XDF teams]

Filed under: Science

Comments

Source: Yale University, UC Santa Cruz