Category Archives: News

Pay by Person: What Biometrics Means to PayPal

Movies like Minority Report and Blade Runner may still be science fiction, but some of the technologies they showcase are becoming a reality today. The ability to sign in by retinal scan, turn on lights with your voice, unlock doors and activate devices with a fingerprint—otherwise known as biometrics, is quickly becoming a standard especially in mobile technologies. Using your person as your passcode has most recently come into the mainstream marketplace with the release of Apple’s iPhone 5s and iOS 7 software, which incorporate fingerprint-scanning technologies to unlock devices and make purchases through the iTunes and Apple App stores. And keeping the iPhone 5s new Touch ID technology in mind, PayPal recently released a study in conjunction with the National Cyber Security Alliance (NCSA) that looked at consumer behaviors and perceptions around mobile devices, including the use of biometrics for security purposes.

Released as part of National Cyber Security Awareness Month (NCSAM), the study collected responses from 1,000 U.S. adults over two days in September of this year with an aim to better understand how consumers use their mobile devices, as well as how much they know about mobile safety issues. According to the study, people are more reliant than ever on mobile, including a growing use of mobile devices for shopping. However, most of those surveyed still do not view mobile as a very secure option for making purchases online or in-store. It was found that 70% did not feel that storing payment information on a smartphone was safe, and more than 60% were unsure about what financial information could be stored on their devices.

Yet, when it came to biometric protections on mobile devices, respondents were open to trying out these new technologies in place of traditional security measures like passwords. Interestingly, more than half of the respondents (53%) said that they would be willing to replace passwords with fingerprints, and 45% would even opt for a retinal scan instead.

In a previous post, we discussed the latest from Apple, and how their fingerprint scanning technology could be a game changer for mobile. With the number of cyber attacks on the rise, identity theft is a major concern for many, so it’s no wonder that people are open to finding a better alternative to PINs and passwords. Passwords are not only easier to crack than ever before, but remembering 20 plus complex logins for various devices and accounts is becoming impossible to manage. While such security methods as two-factor authentication have been gaining traction with users and businesses, these require additional steps and still rely on passwords as the first level of entry.

Even before the iPhone 5s release, PayPal’s Chief Information Security Officer, Michael Barrett, discussed his thoughts on passwords and the potential of biometrics at Interop IT in Las Vegas. According to Barrett, passwords are obsolete and a new standard needs to be found. However, passwords won’t simply go away overnight and are of no use if not activated in the first place. Despite many people being in favor of new biometric technologies, a whopping 56% in the study admitted that they don’t even take the simplest mobile security precaution—setting up a PIN.

While the PayPal survey results speak to the current public sentiment around biometric technologies, it’s also important to explore the impact of using our bodies as identification. The convenience factor of biometrics is definitely a benefit for mobile commerce, where shoppers would only need to scan a finger instead of entering a login to make a purchase. It’s pretty much impossible to forget your fingerprint, but passwords are lost all the time. Because of the potential to make personal authentication seamless and reduce friction when shopping via a mobile device, companies will almost surely follow in Apple’s Touch ID footsteps.

Nevertheless, the possibility of having your password or other personal information stolen is a frightening reality, and adding a biometric aspect ups the stakes even more. Hackers can already do a lot of damage with only a username and password—imagine what they could do with a fingerprint or retina profile. With this in mind, here are some tips on protecting yourself when using these new biometric security tools:

  • More security is better. Use biometrics in conjunction with a PIN or passcode for extra security if possible. While cybercriminals can no longer gain access to your phone by snooping over your shoulder once biometric safeties are in place on your mobile device, adding in extra defenses if they do get in is crucial.
  • Limit the access of your third-party apps. Biometrics can’t keep malicious apps from accessing your information, so always be careful about what permissions each app is allotted.
  • Only download apps from official sources. Third-party app stores and websites are known for fostering risky apps and malware. Stick to downloading from trusted online sources, such as the Apple App Store and Google Play, that both work to ensure the apps don’t contain anything malicious.
  • Limit your usage while connected to public Wi-Fi. Touch ID technology may be able to keep out unwanted users if your phone gets lost or stolen, but it can’t protect from wireless snoopers and sniffers. Never bank or online shop while using free or unreliable Wi-Fi networks. These kinds of transactions should be reserved for secure and private connections.
  • Update your mobile software. Make sure you are using the latest versions of your operating system, browser, and security software. Updates usually contain additional protection against viruses or malware.
  • Don’t forget about mobile security software. Just because biometrics makes it harder for hackers to get into your device or personal accounts, that doesn’t mean you shouldn’t have extra security. McAfee® Mobile Security comes with many features to help protect your mobile devices from a variety of threats.

Learn about the latest mobile security updates and threats, by following our team on Twitter at @McAfeeConsumer or Like us on Facebook.


The post Pay by Person: What Biometrics Means to PayPal appeared first on McAfee Blogs.

Mobile Malware used in sabotage campaign by hackers in the Middle East.

After numerous attempts to sabotage the Oct26 Driving Campaign online, by repeated hacking of sites/accounts as well as defacing of websites which included the official website for the campaign hxxp:// twice in a span of a few days. Additional attempts to derail the movement are now coming to light. Hacker(s) not deterred by just the act of defacing sites have also created and released malware to spread their message. One such example is the discovery by McAfee Mobile Security of Android/HackDrive.


The malware was disguised as an app in support of the online campaign; even using the icon that has come to symbolize the movement of the Oct 26th Driving Campaign, but in reality was designed to spread the same hate propaganda that was placed on the hacked/defaced websites it was being distributed from.

On installation, the malware activates once a headset has been plugged in. Starting off by jamming the audio by repeatedly playing a predefined audio sequence, making it impossible to listen to anything else on the device or carry out a phone conversation; the threat also displays additional message in Arabic text similar to the messages used in the hacked website.

Curiously enough there were additional functionality traced out in the malicious code. The app had the capability to go through the contact database seeking names, phone numbers on an infected device; accompanying this was the ability to allow data to be posted to a remote website, but strangely even though code was there, the app did not actually call on the functionality. This begs the question, is this work in progress and will a later version having additional features.

On the surface the antics used in the app and the website defacing may seem juvenile but make no mistake, this is hate and prejudice manifested into an app. McAfee is closely monitoring the situation for further development and urge users to exercise precaution when attempting to download any software that is tied to any political or activist campaign.

The post Mobile Malware used in sabotage campaign by hackers in the Middle East. appeared first on McAfee Blogs.

Staying Safe and Secure in a Mobile World

October may be known for Halloween and the spooky characters that come out to play, but many people may not realize that this month is also National Cyber Security Awareness Month (NCSAM). Hosted by the U.S. Department of Homeland Security and the National Cyber Security Alliance (NCSA), NCSAM aims to educate and inform people about how they can proactively guard their online information from cyber threats. Celebrating its 10th year, NCSA introduced a full week devoted to programs that build awareness around mobile safety and security. Mobile technology now allows us to take the convenience and productivity of the Internet everywhere we go, in order to stay connected when traveling, shopping, banking, and much more. However, this newfound freedom comes with a price—there are an estimated 556 million victims of cybercrime each year and counting. Mobile crime is on the rise, and security awareness among users needs to keep up. Getting your mobile device hacked or identity stolen is pretty creepy any time of the year, and it’s more common than ever in today’s digital world.

Since their debut in the early 2000s, smartphones have skyrocketed in popularity. As our interest and demand in smartphones has increased, companies have been quick to respond by releasing a constant stream of new phones with exciting features. We recently saw Apple invest in fingerprint technology for its iPhone 5s and other major companies aren’t far behind, debuting higher resolution cameras, sleeker interfaces, and larger screens. Keeping these advances in mind, it’s understandable why we’ve become so tethered to our mobile devices—convenience. Whether we’re looking for directions to a business meeting, checking out the menu for a new restaurant, or just playing Candy Crush, everything is now literally at our fingertips.

However, just as mobile devices have made our lives more convenient, they have also made it far easier for cybercriminals to get ahold of our personal data. If you’re connecting wherever and whenever, cybercriminals have more opportunities to get into your device. For example, according to the McAfee Threats Report: Second Quarter 2013, more than 30,000 new mobile malware threats have been discovered in the first half of this year alone, that’s just shy of the entirety of 2012. It is proving to be a record year for mobile malware. One of the biggest problems in mobile security today is user awareness and the lack of knowledge around appropriate device protection measures. More than 30% of people don’t password protect their mobile devices. And of those that do, 55% admit to having shared their PIN with others, including their children. It’s easy for hackers and cybercriminals to be able to take advantage of this lax security, so smartphone users must be smart about how they use their devices.

NCSAM is all about teaching all of us on how to proactively stay safe online. That is why they added mobile security to this year’s event, to help educate users that the same safeguards we use on our desktops and laptops should be applied to mobile devices. Below are some top safety and security tips that are good to practice across the board on mobile devices:

  • Update your mobile software. Make sure you are using the latest versions of your operating system, browser, and security software. Updates usually contain additional protection against viruses or malware.
  • Secure your device with a strong passcode. You should be the only who knows the passcode to your smartphone. Also make sure to steer clear of easy options such as 1234 or your birth year.
  • Review app permissions before you download. Third-party apps, especially games or entertainment apps, should have limited access to personal data such as location or social networking sites.
  • Limit your usage while connected to public Wi-Fi. Never bank or online shop while using the Wi-Fi at your local coffee shop. These kinds of transactions should be reserved for secure and private connections.
  • If something sounds suspicious, don’t respond. Just like regular web browsing, mobile scams are on the rise. Be wary of fraudulent calls, texts or voicemails that ask for personal information or immediate action.
  • Go the extra mile when it comes to mobile security. Sometimes taking all the precautions you can is just not enough. McAfee® Mobile Security comes with many features to help protect your Android smartphone and tablet from a variety of threats, including location tracking and remote lock and wipe functions should your device become lost or stolen, and virus protection with continuous scanning and monitoring of your mobile activity.

For more on NCSAM, be sure to visit their website. To keep up with the latest security threats, make sure to follow @McAfeeConsumer on Twitter and like us on Facebook.



The post Staying Safe and Secure in a Mobile World appeared first on McAfee Blogs.

Signing email with an NFC smart card on Android

Last time we discussed how to access the SIM card and use it as a secure element to enhance Android applications. One of the main problems with this approach is that since SIM cards are controlled by the MNO any applets running on a commercial SIM have to be approved by them. Needless to say, that considerably limits flexibility. Fortunately, NFC-enabled Android devices can communicate with practically any external contactless smart card, and you can install anything on those. Let’s explore how an NFC smart card can be used to sign email on Android.

NFC smart cards

As discussed in previous posts, a smart card is a secure execution environment on a single chip, typically packaged in a credit-card sized plastic package or the smaller 2FF/3FF/4FF form factors when used as a SIM card. Traditionally, smart cards connect with a card reader using a number of gold-plated contact pads. The pads are used to both provide power to the card and establish serial communication with its I/O interface. Size, electrical characteristics and communication protocols are defined in the 7816 series of ISO standards. Those traditional cards are referred to as ‘contact smart cards‘. Contactless cards on the other hand do not need to have physical contact with the reader. They draw power and communicate with the reader using RF induction. The communication protocol (T=CL) they use is defined in ISO 14443 and is very similar to the T1 protocol used by contact cards. While smart cards that have only a contactless interface do exist, dual-interface cards that have both contacts and an antenna for RF communication are the majority. The underlying RF standard used varies by manufacturer, and both Type A and Type B are common. 
As we know, NFC has three standard modes of operation: reader/writer (R/W), peer-to-peer (P2P) and card emulation (CE) mode. All NFC-enabled Android devices support R/W and P2P mode, and some can provide CE, either using a physical secure element (SE) or software emulation. All that is needed to communicate with a contactless smart card is the basic R/W mode, so they can be used on practically all Android devices with NFC support. This functionality is provided by the IsoDep class. It provides only basic command-response exchange functionality with the transceive() method, any higher level protocol need to be implemented by the client application.

Securing email

There have been quite a few new services that are trying to reinvent secure email in recent years. They are trying to make it ‘easy’ for users by taking care of key management and shifting all cryptographic operations to the server. As recent events have reconfirmed, introducing an intermediary is not a very good idea if communication between two parties is to be and remain secure. Secure email itself is hardly a new idea, and the ‘old-school’ way of implementing it relies on pubic key cryptography. Each party is responsible for both protecting their private key and verifying that the public key of their counterpart matches their actual identity. The method used to verify identity is the biggest difference between the two major secure email standards in use today, PGP and S/MIME. PGP relies on the so called ‘web of trust’, where everyone can vouch for the identity of someone by signing their key (usually after meeting them in person), and keys with more signatures can be considered trustworthy. S/MIME, on the other hand, relies on PKI and X.509 certificates, where the issuing authority (CA) is relied upon to verify identity when issuing a certificate. PGP has the advantage of being decentralized, which makes it harder to break the system by compromising  a single entity, as has happened with a number of public CAs in recent years. However, it requires much more user involvement and is especially challenging to new users. Additionally, while many commercial and open source PGP implementations do exist, most mainstream email clients do not support PGP out of the box and require the installation of plugins and additional software. On the other hand, all major proprietary (Outlook variants,, etc) and open source (Thunderbird) email clients have built-in and mature S/MIME implementations. We will use S/MIME for this example because it is a lot easier to get started with and test, but the techniques described can be used to implement PGP-secured email as well. Let’s first discuss how S/MIME is implemented.

Signing with S/MIME

The S/MIME, or Secure/Multipurpose Internet Mail Extensions, standard defines how to include signed and/or encrypted content in email messages. It specified both the procedures for creating  signed or encrypted (enveloped) content and the MIME media types to use when adding them to the message. For example, a signed message would have a part with the Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data which contains the message signature and any associated attributes. To an email client that does not support S/MIME, like most Web mail apps, this would look like an attachment called smime.p7s. S/MIME-compliant clients would instead parse and verify the signature and display some visual indication showing the signature verification status.

The more interesting question however is what’s in smime.p7s? The ‘p7’ stands for PKCS#7, which is the predecessor of the current Cryptographic Message Syntax (CMS). CMS defines structures used to package signed, authenticated or encrypted content and related attributes. As with most PKI X.509-derived standards, those structures are ASN.1 based and encoded into binary using DER, just like certificates and CRLs. They are sequences of other structures, which are in turn composed of yet other ASN.1 structures, which are…, basically sequences all the way down. Let’s try to look at the higher-level ones used for signed email. The CMS structure describing signed content is predictably called SignedData and looks like this:

SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }

Here digestAlgorithms contains the OIDs of the hash algorithms used to produce the signature (one for each signer) and encapContentInfo describes the data that was signed, and can optionally contain the actual data. The optional certificates and crls fields are intended to help verify the signer certificate. If absent, the verifier is responsible for collecting them by other means. The most interesting part, signerInfos, contains the actual signature and information about the signer. It looks like this:

SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Besides the signature value and algorithms used, SignedInfo contains signer identifier used to find the exact certificate that was used and a number of optional signed and unsigned attributes. Signed attributes are included when producing the signature value and can contain additional information about the signature, such as signing time. Unsigned attribute are not covered by the signature value, but can contain signed data themselves, such as counter signature (an additional signature over the signature value).

To sum this up, in order to produce a S/MIME signed message, we need to sign the email contents and any attributes, generate the SignedInfo structure, wrap it into a SignedData, DER encode the result and add it to the message using the appropriate MIME type. Sound easy, right? Let’s how this can be done on Android.

Using S/MIME on Android

On any platform, you need two things in order to generate an S/MIME message: a cryptographic provider that can perform the actual signing using an asymmetric key and an ASN.1 parser/generator in order to generate the SignedData structure. Android has JCE providers that support RSA, recently even with hardware-backed keys. What’s left is an ASN.1 generator. While ASN.1 and DER/BER have been around for ages, and there are quite a few parsers/generators, the practically useful choices  are not that many. No one really generates code directly from the ASN.1 modules found in related standards, most libraries implement only the necessary parts, building on available components. Both of Android’s major cryptographic libraries, OpenSSL and Bouncy Castle contain ASN.1 parser/generators and have support for CMS. The related API’s are not public though, so we need to include our own libraries.

As usual we turn to Spongy Castle, which is provides all of Bouncy Castle’s functionality under a different namespace. In order to be able process CMS and generate S/MIME messages, we need the optional scpkix and scmail packages. The first one contains PKIX and CMS related classes, and the second one implements S/MIME. However, there is a twist: Android lacks some of the classes required for generating S/MIME messages. As you may know, Android has implementations for most standard Java APIs, with a few exceptions, most notably the GUI widget related AWT and Swing packages. Those are rarely missed, because Android has its own widget and graphics libraries. However, besides widgets AWT contains classes related to MIME media types as well. Unfortunately, some of those are  used in libraries that deal with MIME objects, such as JavaMail and the Bouncy Castle S/MIME implementation. JavaMail versions that include alternative AWT implementations, repackaged for Android have been available for some time, but since they use some non-standard package names, they are not a drop-in replacement. That applies to Spongy Castle as well: some source code modifications are required in order to get scmail to work with the javamail-android library.

With that sorted out, generating an S/MIME message on Android is just a matter of finding the signer key and certificate and using the proper Bouncy Castle and JavaMail APIs to generate and send the message:

PrivateKey signerKey = KeyChain.getPrivateKey(ctx, "smime");
X509Certificate[] chain = KeyChain.getCertificateChain(ctx, "smime");
X509Certificate signerCert = chain[0];
X509Certificate caCert = chain[1];

SMIMESignedGenerator gen = new SMIMESignedGenerator();
gen.addSignerInfoGenerator(new JcaSimpleSignerInfoGeneratorBuilder()
new AttributeTable(signedAttrs))
.build("SHA512withRSA", signerKey, signerCert));
Store certs = new JcaCertStore(Arrays.asList(signerCert, caCert));

MimeMultipart mm = gen.generate(mimeMsg, "SC");
MimeMessage signedMessage = new MimeMessage(session);
Enumeration headers = mimeMsg.getAllHeaderLines();
while (headers.hasMoreElements()) {
signedMessage.addHeaderLine((String) headers.nextElement());


Here we first get the signer key and certificate using the KeyChain API and then create an S/MIME generator by specifying the key, certificate, signature algorithm and signed attributes. Note that we specify the AndroidOpenSSL provider explicitly which is the only one that can use hardware-backed keys. This is only required if you changed the default provider order when installing Spongy Castle, by default AndroidOpenSSL is the preferred JCE provider. We then add the certificates we want to include in the generated SignedData and generate a multi-part MIME message that includes both the original message (mimeMsg) and the signature. Finally we send the message using the JavaMail Transport class. The JavaMail Session initialization is omitted from the example above, see the sample app for how to set it up to use Gmail’s SMTP server. This requires the Gmail account password to be specified, but with a little more work it can be replaced with an OAuth token you can obtain from the system AccountManager.

So what about smart cards?

Using a MuscleCard to sign email

In order to sign email using keys stored on a smart card we need a few things: 
  • a dual-interface smart cards that supports RSA keys
  • a crypto applet that allows us to sign data with those keys
  • some sort of middleware that exposes card functionality through a standard crypto API

Most recent dual-interface JavaCards fulfill our requirements, but we will be using a NXP J3A081 which supports JavaCard 2.2.2 and 2048-bit RSA keys. When it comes to open source crypto applets though, unfortunately the choices are quite limited. Just about the only one that is both full-featured and well supported in middleware libraries is the venerable MuscleCard applet. We will be using one of the fairly recent forks, updated to support JavaCard 2.2 and extended APDUs. To load the applet on the card you need a GlobalPlatform-compatible loader application, like GPJ, and of course the CardManager keys. Once you have initialized it, you can personalize it by generating or importing keys and certificates. After that the card can be used in any application that supports PKCS#11, for example Thunderbird and Firefox. Because the card is dual-interface, practically any smart card reader can be used on desktops. When the OpenSC PKCS#11 module is loaded in Thunderbird the card will show up in the Security Devices dialog like this:

If the certificate installed in the card has your email in the Subject Alternative Name extension, you should be able send signed and encrypted emails (if you have the recipient’s certificate, of course). But how to achieve the same thing in Android?

Using MuscleCard on Android

Android doesn’t support PKCS#11 modules, so in order to expose the cards crypto functionality we could implement a custom JCE provider that provides card-backed implementations of the Signature and KeyStrore engine classes. That is quite a bit of work though, and since we are only targeting the Bouncy Castle S/MIME API, we can get away by implementing the ContentSigner interface. It provides an OutputStream clients write data to be signed to, an AlgorithmIdentifer for the signature method used and a getSignature() method that returns the actual signature value. Our MuscleCard-backed implementation could look like this:

class MuscleCardContentSigner implements ContentSigner {

private ByteArrayOutputStream baos = new ByteArrayOutputStream();
private MuscleCard msc;
private String pin;
public byte[] getSignature() {;

byte[] data = baos.toByteArray();
return msc.sign(data);

Here the MuscleCard class is our ‘middleware’ and encapsulates the card’s RSA signature functionality. It is implemented by sending the required command APDUs for each operation using Android’s IsoDep API and aggregating and converting the result as needed. For example, the verifyPin() is implemented like this:

class MuscleCard {

private IsoDep tag;

public boolean verifyPin(String pin) throws IOException {
String cmd = String.format("B0 42 01 00 %02x %s", pin.length(),
ResponseApdu rapdu = new ResponseApdu(tag.transceive(fromHex(cmd)));
if (rapdu.getSW() != SW_SUCCESS) {
return false;

return true;

Signing is a little more complicated because it involves creating and updating temporary I/O objects, but follows the same principle. Since the applet does not support padding or hashing, we need to generate and pad the PKCS#1 (or PSS) signature block on Android and send the complete data to the card. Finally, we need to plug our signer implementation into the Bouncy Castle CMS generator:

ContentSigner mscCs = new MuscleCardContentSigner(muscleCard, pin);
gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(
new JcaDigestCalculatorProviderBuilder()
.build()).build(mscCs, cardCert));

After that the signed message can be generated exactly like when using local key store keys. Of course, there are a few caveats. Since apps cannot control when an NFC connection is established, we can only sign data after the card has been picked up by the device and we have received an Intent with a live IsoDep instance. Additionally, since signing can take a few seconds, we need to make sure the connection is not broken by placing the device on top of the card (or use some sort of awkward case with a card slot). Our implementation also takes a few shortcuts by hard-coding the certificate object ID and size, as well as the card PIN, but those can be remedied with a little more code. The UI of our homebrew S/MIME client is shown below.

After you import a PKCS#12 file in the system credential store you can sign emails using the imported keys. The ‘Sign with NFC’ button is only enabled when a compatible card has been detected. The easiest way to verify the email signature is to send a message to a desktop client that supports S/MIME. There are also a few Android email apps that support S/MIME, but setup can be a bit challenging because they often use their own trust and key stores. You can also dump the generated message to external storage using MimeMessage.writeTo() and then parse the CMS structure using the OpenSSL cms command:

$ openssl cms -cmsout -in signed.message -noout -print
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
version: 1
algorithm: sha512 (2.16.840.
parameter: NULL
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent: <absent>
version: 2
serialNumber: 4
algorithm: sha1WithRSAEncryption (1.2.840.113549.1.1.5)
version: 1
issuer: C=JP, ST=Tokyo, CN=keystore-test-CA
serialNumber: 3
algorithm: sha512 (2.16.840.
parameter: NULL
object: contentType (1.2.840.113549.1.9.3)
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)

object: signingTime (1.2.840.113549.1.9.5)
UTCTIME:Oct 25 16:25:29 2013 GMT

object: messageDigest (1.2.840.113549.1.9.4)
0000 - 88 bd 87 84 15 53 3d d8-72 64 c7 36 f8 .....S=.rd.6.
000d - b0 f3 39 90 b2 a4 77 56-5c 9f e4 2e 7c ..9...wV...|
001a - 7d 2e 0b 08 b4 b7 e7 6c-e9 b6 61 00 13 }......l..a..
0027 - 25 62 69 2a bc 08 5b 4c-4f c9 73 cf d3 %bi*..[LO.s..
0034 - c6 1e 51 c2 5f c1 64 77-3b 45 e2 cb ..Q._.dw;E..
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
0000 - a0 d0 ce 35 46 8c f9 cd-e5 db ed d8 e3 f0 08 ...5F..........

Email encryption using the NFC smart card can be implemented in a similar fashion, but this time the card will be required when decrypting the message.


Practically all NFC-enabled Android devices can be used to communicate with a contactless or dual-interface smart card. If the interface of card applications is known, it is fairly easy to implement an Android component that exposes card functionality via a custom interface, or even as a standard JCE provider. The card’s cryptographic functionality can then be used to secure email or provide HTTPS and VPN authentication. This could be especially useful when dealing with keys that have been generated on the card and cannot be extracted. If a PKCS#12 backup file is available, importing the file in the system credential store can provide a better user experience and comparable security levels if the device has a hardware-backed credential store. 

Putting Your Best Finger Forward: You are Your Password with Appleā€™s new Biometric Technology

With the release of the new iPhone 5s and iOS 7 software, Apple is making headlines around a number of new features including a huge upgrade to its security offerings. The updates have a lot of people talking about how Apple fits into the mobile device safety conversation and how this could be a game-changer when it comes to fingerprint scanning technologies for mobile.

Fingerprint ID technology opens a number of doors but also raises several questions about how safe and user-friendly this new technology will be. Let’s take a look at the new Touch ID, what it does, how it works, and some pros and cons to relying on it for securing your phone.

  • Don’t let your thumb have all the fun. You have the option to save multiple fingerprints to the iPhone 5s Touch ID chip. This can be convenient if you need to use other fingers to unlock your phone, say if one hand is full
  • Will I no longer need a passcode? While Touch ID is meant to “minimize” the use of your passcode, according to Apple, it does not eliminate it. A passcode is still necessary for additional security validation, such as enrolling new fingerprints, and signing into your phone should you need to restart or reboot.
  • Use Touch ID for more than unlocking your phone. You can also make purchases on iTunes, the Apple App Store and the iBooks Store with your fingerprint. Possibly in the future, new technologies could arise that would allow you to make purchases via other apps.
  • Adjust the settings of your Touch ID. You can select which individual functions are accessed through the scanning chip in your phone’s home button. You can set it to only unlock your phone, only approve iTunes purchases, or do both.
  • Is my fingerprint stored and shared on some secret database? No, Apple has been very clear that the print you scan stays on the Touch ID chip and goes nowhere else.


Screen Shot 2013-10-10 at 5.23.38 PM

And while Touch ID shows a growing sensibility on the part of Apple toward the need for stronger protection of mobile devices, Apple has also unleashed a number of software upgrades with the release of iOS 7 to protect users from the growing threat of mobile malware. Additional updates include: privacy controls on web searching and third-party app permissions, password management through iCloud, and restricting automatic access to your phone’s data when you plug into a laptop or computer for power.

Right now though, biometrics is the hot topic, with a number of companies trying to incorporate features such as voice recognition, fingerprint scanning and more into new technologies. Touch ID isn’t foolproof, yet so far, people are clamoring to get their finger on the new technology. Even with all of these new features, however, you should still exercise the following general precautions to protect your mobile device:

  • Lock your device. Even if you aren’t the lucky owner of a new iPhone 5s, most smartphones offer the option of a PIN code. You’ll definitely appreciate the added protection should your phone ever fall into the wrong hands.
  • Regularly change and update passcodes. One benefit of Touch ID is that cybercriminals can no longer access your phone by snooping over your shoulder hoping to glimpse a passcode as you enter it. However, if you own an older model iPhone or Android device, be sure you change passcodes frequently to lessen the chances of anyone gaining access to your device if lost or stolen.
  • Limit the access of your third-party apps. Many shady app creators try to obtain information they do not need by pulling more data not necessary for the app to function from your phone. Under Settings you can view and grant/restrict which apps use your location, camera, microphone or other data and which can have access to your social networks.
  • Only download apps from official sources. Third-party app stores and websites can be a breeding ground for risky apps and malware. Stick to downloading apps from trusted online sources, such as the Apple App Store, that have protocols in place to ensure the apps they sell don’t contain anything malicious.
  • Do not log into apps that hold sensitive data while you’re using public Wi-Fi. You are practically handing over your sensitive data to a cyber snoop you who may be nearby. Many hackers set up shop in coffee houses, libraries and other public areas just waiting for an the unsuspecting to sign onto the shared Wi-Fi.
  • Always install app updates as they’re made available. Many address known bugs and apply patches to security holes. The iPhone 5s and iOS 7 update offer a background-downloading feature, new to Apple, to enable auto-updates.

Get in touch with your mobile phone security needs. Learn about the latest mobile security updates and threats, by following our team on Twitter at @McAfeeConsumer or Like us on Facebook.


The post Putting Your Best Finger Forward: You are Your Password with Apple’s new Biometric Technology appeared first on McAfee Blogs.