Tampilkan postingan dengan label Security. Tampilkan semua postingan
Tampilkan postingan dengan label Security. Tampilkan semua postingan

Changes to the SecretKeyFactory API in Android 4.4

Posted by muamar Kamis, 12 Desember 2013 0 komentar
random_droid


In order to encrypt data, you need two things: some data to encrypt and an encryption key. The encryption key is typically a 128- or 256-bit integer. However, most people would rather use a short passphrase instead of a remembering a 78-digit number, so Android provides a way to generate an encryption key from ASCII text inside of javax.crypto.SecretKeyFactory.



Beginning with Android 4.4 KitKat, we’ve made a subtle change to the behavior of SecretKeyFactory. This change may break some applications that use symmetric encryption and meet all of the following conditions:




  1. Use SecretKeyFactory to generate symmetric keys, and

  2. Use PBKDF2WithHmacSHA1 as their key generation algorithm for SecretKeyFactory, and

  3. Allow Unicode input for passphrases



Specifically, PBKDF2WithHmacSHA1 only looks at the lower 8 bits of Java characters in passphrases on devices running Android 4.3 or below. Beginning with Android 4.4, we have changed this implementation to use all available bits in Unicode characters, in compliance with recommendations in PCKS #5.



Users using only ASCII characters in passphrases will see no difference. However, passphrases using higher-order Unicode characters will result in a different key being generated on devices running Android 4.4 and later.



For backward compatibility, we have added a new key generation algorithm which preserves the old behavior: PBKDF2WithHmacSHA1And8bit. Applications that need to preserve compatibility with older platform versions (pre API 19) and meet the conditions above can make use of this code:



import android.os.Build;

SecretKeyFactory factory;
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
// Use compatibility key factory -- only uses lower 8-bits of passphrase chars
factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1And8bit");
} else {
// Traditional key factory. Will use lower 8-bits of passphrase chars on
// older Android versions (API level 18 and lower) and all available bits
// on KitKat and newer (API level 19 and higher).
factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
}




Baca Selengkapnya ....

Google Settings Page for Phone Numbers

Posted by muamar Selasa, 10 Desember 2013 0 komentar
Google's account settings page has an updated section for phone numbers that groups some features that were already available elsewhere. If you click "edit" next to "phone numbers", Google will show the phone numbers associated with your account.

You'll probably see a phone number associated with Hangouts. You can enable or disable this setting: "Help people who have your phone number find and connect with you on Google services, like Hangouts and caller ID by Google." You can edit the phone number, change the way it's verified or remove the number.

There's also a phone number that's used for account recovery. Google encourages users to enable this feature, but it's optional. For now, the account recovery page is not integrated with the account settings page, so it looks different and has a long URL. "We'll use your phone to do things like challenge hijackers or send you a text message to help you access your account if you forget your password," informs Google.



The phone number management page was added back in May, but now it's more functional.

{ Thanks, Herin. }

Baca Selengkapnya ....

New Interface for Google's Account Permissions Page

Posted by muamar Rabu, 27 November 2013 0 komentar
Google's account permissions page has a new interface which does a better job at listing the permissions, shows bigger thumbnails and the date when you authorized a service.

"On the Account Permissions tab of your Google Account, you can see a list of third-party sites and applications. These are sites and applications to which you've granted permission to access your Google Account, and you can see on this list to what parts of your account they have access. For example, you might have downloaded an app that helps you schedule workouts with friends. This application might have requested access to your Google Calendar and Contacts to suggest times and friends for you to meet up with," informs Google's help center.

Google shows your Android and iOS devices at the top of the page. My Nexus 7 tablet was listed 3 times, so I clicked "Revoke access" next to the entries that include: "Inactive - We haven't seen activity from this device for at least 60 days."


If you see some services you no longer use, click "Revoke access". You'll be asked for permission the next time you use them.

{ Thanks, Florian K. }

Baca Selengkapnya ....

Google Operating System, Again a Phishing Site?

Posted by muamar Rabu, 06 November 2013 0 komentar
Back in September, I wrote about Netcraft, who incorrectly flagged this blog as phishing. Many applications use the Netcraft backlist, so Opera, Kaspersky and probably other apps prevent users from visiting this site. I reported this issue to Netcraft, who solved it, but the site was added again to the blacklist a few days later. A Netcraft employee promised to flag the site as safe.

The issue is that Netcraft only flagged googlesystem.blogspot.com. Blogger redirects to domains like blogspot.co.uk, blogspot.ro, depending on your country. Now Netcraft flags as phishing all googlesystem.blogspot.* URLs, except for googlesystem.blogspot.com. According to VirusTotal, security tools from ESET, Fortinet and Kaspersky show phishing warnings for this blog.



Google Safe Browsing also shows a phishing warning for googlesystem.blogspot.ca, googlesystem.blogspot.se, googlesystem.blogspot.ro, googlesystem.blogspot.com.br and probably other similar URLs. Google Safe Browsing is used by Chrome, Firefox, and Safari for desktop. "Reported Phishing Website Ahead! Google Chrome has blocked access to googlesystem.blogspot.com.br. This website has been reported as a phishing website. Phishing websites are designed to trick you into disclosing your login, password or other sensitive information by disguising themselves as other websites you may trust."


I reported this issue to Netcraft and Google, so hopefully it will be solved. I just don't understand what triggered these phishing warnings and why they're no longer limited to Netcraft.

Update: After a few hours, the issue was fixed.

{ Thanks, Manuel Janeiro. }

Baca Selengkapnya ....

Google Operating System, Phishing Site?

Posted by muamar Rabu, 11 September 2013 0 komentar
If you use Opera to visit the site, you'll probably see this warning: "This site has been reported as fraudulent. Exchanging sensitive or confidential information with this site could put you at risk for identity theft and/or financial fraud. Opera Software strongly discourages visiting this page."


Opera uses Netcraft's phishing blacklist. You'll get a similar warning if you install Netcraft's toolbar:


Netcraft's site report page doesn't provide too many useful information. I could only find that the Google OS blog has a 5/10 risk rating, but the rating varies depending on the URL. The recent post about the Google logo has a 7/10 risk rating.


Many factors contribute to the risk rating of each site. The dominant factor for most sites is the age of the domain name in which the site appears. Domain names that have never been seen in the Netcraft Web Server Survey are given a high risk rating, since many phishing sites and relatively few legitimate sites fall into this category. Other factors which can influence the risk rating include:

* Any other known phishing sites in the same domain.
* Whether a hostname or a numeric IP address is used in the URL.
* Whether or not a port number appears in the URL.
* The hosting ISP's history with respect to phishing sites.
* The hosting country's history with respect to phishing sites.
* The top level domain's history with respect to phishing sites.
* The site's popularity with Netcraft Extension users.

So just because other Blogger blogs are used for phishing, Netcraft decided that this is a phishing site? It's hard to say. Google's official blog has a 0/10 risk rating, while a random blog like googlelatlong.blogspot.com (it's not Google's Maps blog) has a 7/10 risk rating, but there's no warning.

A site that lets you check multiple anti-phishing blacklists is the Google-owned VirusTotal. "VirusTotal is a free service that analyzes suspicious files and URLs and facilitates the quick detection of viruses, worms, trojans, and all kinds of malware." VirusTotal reported that there are 3 services that flag the Google OS blog: Opera, Netcraft and Kaspersky. They probably have the same source.


Here's Kaspersky's "access denied" message:


Ironically, a recent blog post from Kaspersky's site informs that: "Kaspersky's product blocked 99 percent of the 187 phishing websites while producing zero false alarms among the 400 legitimate URLs, earning first place among its competitors with an Advanced + award from AV-Comparatives."

I used Netcraft's browser extension to report that the URL was flagged by mistake and received this message after a few minutes: "Thank you for your enquiry. Following a review of the URL in question, I have unblocked the URL from the toolbar. Please allow a short period of time for the changes to propagate."


{ Thanks, Josh Rich. He reported this issue. }

Baca Selengkapnya ....

Some SecureRandom Thoughts

Posted by muamar Rabu, 14 Agustus 2013 0 komentar


The Android security team has been investigating the root cause of the compromise of a bitcoin transaction that led to the update of multiple Bitcoin applications on August 11.



We have now determined that applications which use the Java Cryptography Architecture (JCA) for key generation, signing, or random number generation may not receive cryptographically strong values on Android devices due to improper initialization of the underlying PRNG. Applications that directly invoke the system-provided OpenSSL PRNG without explicit initialization on Android are also affected. Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from /dev/urandom.



Developers who use JCA for key generation, signing or random number generation should update their applications to explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random. A suggested implementation is provided at the end of this blog post. Also, developers should evaluate whether to regenerate cryptographic keys or other random values previously generated using JCA APIs such as SecureRandom, KeyGenerator, KeyPairGenerator, KeyAgreement, and Signature.



In addition to this developer recommendation, Android has developed patches that ensure that Android’s OpenSSL PRNG is initialized correctly. Those patches have been provided to OHA partners.



We would like to thank Soo Hyeon Kim, Daewan Han of ETRI and Dong Hoon Lee of Korea University who notified Google about the improper initialization of OpenSSL PRNG.



Update: the original code sample below crashed on a small fraction of Android devices due to /dev/urandom not being writable. We have now updated the code sample to handle this case gracefully.



/*
* This software is provided 'as-is', without any express or implied
* warranty. In no event will Google be held liable for any damages
* arising from the use of this software.
*
* Permission is granted to anyone to use this software for any purpose,
* including commercial applications, and to alter it and redistribute it
* freely, as long as the origin is not misrepresented.
*/

import android.os.Build;
import android.os.Process;
import android.util.Log;

import java.io.ByteArrayOutputStream;
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.io.UnsupportedEncodingException;
import java.security.NoSuchAlgorithmException;
import java.security.Provider;
import java.security.SecureRandom;
import java.security.SecureRandomSpi;
import java.security.Security;

/**
* Fixes for the output of the default PRNG having low entropy.
*
* The fixes need to be applied via {@link #apply()} before any use of Java
* Cryptography Architecture primitives. A good place to invoke them is in the
* application's {@code onCreate}.
*/
public final class PRNGFixes {

private static final int VERSION_CODE_JELLY_BEAN = 16;
private static final int VERSION_CODE_JELLY_BEAN_MR2 = 18;
private static final byte[] BUILD_FINGERPRINT_AND_DEVICE_SERIAL =
getBuildFingerprintAndDeviceSerial();

/** Hidden constructor to prevent instantiation. */
private PRNGFixes() {}

/**
* Applies all fixes.
*
* @throws SecurityException if a fix is needed but could not be applied.
*/
public static void apply() {
applyOpenSSLFix();
installLinuxPRNGSecureRandom();
}

/**
* Applies the fix for OpenSSL PRNG having low entropy. Does nothing if the
* fix is not needed.
*
* @throws SecurityException if the fix is needed but could not be applied.
*/
private static void applyOpenSSLFix() throws SecurityException {
if ((Build.VERSION.SDK_INT < VERSION_CODE_JELLY_BEAN)
|| (Build.VERSION.SDK_INT > VERSION_CODE_JELLY_BEAN_MR2)) {
// No need to apply the fix
return;
}

try {
// Mix in the device- and invocation-specific seed.
Class.forName("org.apache.harmony.xnet.provider.jsse.NativeCrypto")
.getMethod("RAND_seed", byte[].class)
.invoke(null, generateSeed());

// Mix output of Linux PRNG into OpenSSL's PRNG
int bytesRead = (Integer) Class.forName(
"org.apache.harmony.xnet.provider.jsse.NativeCrypto")
.getMethod("RAND_load_file", String.class, long.class)
.invoke(null, "/dev/urandom", 1024);
if (bytesRead != 1024) {
throw new IOException(
"Unexpected number of bytes read from Linux PRNG: "
+ bytesRead);
}
} catch (Exception e) {
throw new SecurityException("Failed to seed OpenSSL PRNG", e);
}
}

/**
* Installs a Linux PRNG-backed {@code SecureRandom} implementation as the
* default. Does nothing if the implementation is already the default or if
* there is not need to install the implementation.
*
* @throws SecurityException if the fix is needed but could not be applied.
*/
private static void installLinuxPRNGSecureRandom()
throws SecurityException {
if (Build.VERSION.SDK_INT > VERSION_CODE_JELLY_BEAN_MR2) {
// No need to apply the fix
return;
}

// Install a Linux PRNG-based SecureRandom implementation as the
// default, if not yet installed.
Provider[] secureRandomProviders =
Security.getProviders("SecureRandom.SHA1PRNG");
if ((secureRandomProviders == null)
|| (secureRandomProviders.length < 1)
|| (!LinuxPRNGSecureRandomProvider.class.equals(
secureRandomProviders[0].getClass()))) {
Security.insertProviderAt(new LinuxPRNGSecureRandomProvider(), 1);
}

// Assert that new SecureRandom() and
// SecureRandom.getInstance("SHA1PRNG") return a SecureRandom backed
// by the Linux PRNG-based SecureRandom implementation.
SecureRandom rng1 = new SecureRandom();
if (!LinuxPRNGSecureRandomProvider.class.equals(
rng1.getProvider().getClass())) {
throw new SecurityException(
"new SecureRandom() backed by wrong Provider: "
+ rng1.getProvider().getClass());
}

SecureRandom rng2;
try {
rng2 = SecureRandom.getInstance("SHA1PRNG");
} catch (NoSuchAlgorithmException e) {
throw new SecurityException("SHA1PRNG not available", e);
}
if (!LinuxPRNGSecureRandomProvider.class.equals(
rng2.getProvider().getClass())) {
throw new SecurityException(
"SecureRandom.getInstance(\"SHA1PRNG\") backed by wrong"
+ " Provider: " + rng2.getProvider().getClass());
}
}

/**
* {@code Provider} of {@code SecureRandom} engines which pass through
* all requests to the Linux PRNG.
*/
private static class LinuxPRNGSecureRandomProvider extends Provider {

public LinuxPRNGSecureRandomProvider() {
super("LinuxPRNG",
1.0,
"A Linux-specific random number provider that uses"
+ " /dev/urandom");
// Although /dev/urandom is not a SHA-1 PRNG, some apps
// explicitly request a SHA1PRNG SecureRandom and we thus need to
// prevent them from getting the default implementation whose output
// may have low entropy.
put("SecureRandom.SHA1PRNG", LinuxPRNGSecureRandom.class.getName());
put("SecureRandom.SHA1PRNG ImplementedIn", "Software");
}
}

/**
* {@link SecureRandomSpi} which passes all requests to the Linux PRNG
* ({@code /dev/urandom}).
*/
public static class LinuxPRNGSecureRandom extends SecureRandomSpi {

/*
* IMPLEMENTATION NOTE: Requests to generate bytes and to mix in a seed
* are passed through to the Linux PRNG (/dev/urandom). Instances of
* this class seed themselves by mixing in the current time, PID, UID,
* build fingerprint, and hardware serial number (where available) into
* Linux PRNG.
*
* Concurrency: Read requests to the underlying Linux PRNG are
* serialized (on sLock) to ensure that multiple threads do not get
* duplicated PRNG output.
*/

private static final File URANDOM_FILE = new File("/dev/urandom");

private static final Object sLock = new Object();

/**
* Input stream for reading from Linux PRNG or {@code null} if not yet
* opened.
*
* @GuardedBy("sLock")
*/
private static DataInputStream sUrandomIn;

/**
* Output stream for writing to Linux PRNG or {@code null} if not yet
* opened.
*
* @GuardedBy("sLock")
*/
private static OutputStream sUrandomOut;

/**
* Whether this engine instance has been seeded. This is needed because
* each instance needs to seed itself if the client does not explicitly
* seed it.
*/
private boolean mSeeded;

@Override
protected void engineSetSeed(byte[] bytes) {
try {
OutputStream out;
synchronized (sLock) {
out = getUrandomOutputStream();
}
out.write(bytes);
out.flush();
} catch (IOException e) {
// On a small fraction of devices /dev/urandom is not writable.
// Log and ignore.
Log.w(PRNGFixes.class.getSimpleName(),
"Failed to mix seed into " + URANDOM_FILE);
} finally {
mSeeded = true;
}
}

@Override
protected void engineNextBytes(byte[] bytes) {
if (!mSeeded) {
// Mix in the device- and invocation-specific seed.
engineSetSeed(generateSeed());
}

try {
DataInputStream in;
synchronized (sLock) {
in = getUrandomInputStream();
}
synchronized (in) {
in.readFully(bytes);
}
} catch (IOException e) {
throw new SecurityException(
"Failed to read from " + URANDOM_FILE, e);
}
}

@Override
protected byte[] engineGenerateSeed(int size) {
byte[] seed = new byte[size];
engineNextBytes(seed);
return seed;
}

private DataInputStream getUrandomInputStream() {
synchronized (sLock) {
if (sUrandomIn == null) {
// NOTE: Consider inserting a BufferedInputStream between
// DataInputStream and FileInputStream if you need higher
// PRNG output performance and can live with future PRNG
// output being pulled into this process prematurely.
try {
sUrandomIn = new DataInputStream(
new FileInputStream(URANDOM_FILE));
} catch (IOException e) {
throw new SecurityException("Failed to open "
+ URANDOM_FILE + " for reading", e);
}
}
return sUrandomIn;
}
}

private OutputStream getUrandomOutputStream() throws IOException {
synchronized (sLock) {
if (sUrandomOut == null) {
sUrandomOut = new FileOutputStream(URANDOM_FILE);
}
return sUrandomOut;
}
}
}

/**
* Generates a device- and invocation-specific seed to be mixed into the
* Linux PRNG.
*/
private static byte[] generateSeed() {
try {
ByteArrayOutputStream seedBuffer = new ByteArrayOutputStream();
DataOutputStream seedBufferOut =
new DataOutputStream(seedBuffer);
seedBufferOut.writeLong(System.currentTimeMillis());
seedBufferOut.writeLong(System.nanoTime());
seedBufferOut.writeInt(Process.myPid());
seedBufferOut.writeInt(Process.myUid());
seedBufferOut.write(BUILD_FINGERPRINT_AND_DEVICE_SERIAL);
seedBufferOut.close();
return seedBuffer.toByteArray();
} catch (IOException e) {
throw new SecurityException("Failed to generate seed", e);
}
}

/**
* Gets the hardware serial number of this device.
*
* @return serial number or {@code null} if not available.
*/
private static String getDeviceSerialNumber() {
// We're using the Reflection API because Build.SERIAL is only available
// since API Level 9 (Gingerbread, Android 2.3).
try {
return (String) Build.class.getField("SERIAL").get(null);
} catch (Exception ignored) {
return null;
}
}

private static byte[] getBuildFingerprintAndDeviceSerial() {
StringBuilder result = new StringBuilder();
String fingerprint = Build.FINGERPRINT;
if (fingerprint != null) {
result.append(fingerprint);
}
String serial = getDeviceSerialNumber();
if (serial != null) {
result.append(serial);
}
try {
return result.toString().getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
throw new RuntimeException("UTF-8 encoding not supported");
}
}
}




Baca Selengkapnya ....

The Android Bug 8219321

Posted by muamar Rabu, 10 Juli 2013 0 komentar
There's a lot of talk about an Android security bug that affects almost all the Android devices. Jeff Forristal from Bluebox Security reported that "the vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature. Details of Android security bug 8219321 were responsibly disclosed through Bluebox Security's close relationship with Google in February 2013."

So the bug could allow someone to create a modified version of an system app and trick other people to install it. The modified version could include malicious code.

Actually, the bug is simple: APK files are ZIP archives and Android allows APK files to include files with the same name. "It's a problem in the way Android handles APKs that have duplicate file names inside," says Pau Oliva Fora, security engineer at security firm ViaForensics. "The entry which is verified for signature is the second one inside the APK, and the entry which ends up being installed is the first one inside the APK - the injected one that can contain the malicious payload and is not checked for signature at all."

The problem is that Android supported duplicate file names in APKs and the patch removed this support. The patch is extremely simple: return an error if the APK file has duplicate file names.


Apparently, Geremy Condra from Google wrote a patch in February. "Google made changes to Google Play in order to detect apps modified in this way and a patch has already been shared with device manufacturers," informs ComputerWorld. CyanogenMod included the bug fix in the latest release, faster than OEMs and even Google, which didn't update Nexus devices to address this issue.

The bug #8219321 is now a test that will show us how fast Google, OEMs and carriers can deploy security patches. For now, CyanogenMod is the place to go to get the latest features and security patches.

Baca Selengkapnya ....

Google Shows Your Recent Sign-ins

Posted by muamar Kamis, 13 Juni 2013 0 komentar
There's a new section in the Google Account settings page: recent activity. Google shows a list of recent sign-ins and other security-related actions, with information about the browser, device, IP address and approximate location.


The feature seems similar to Gmail's account activity feature, but it's not. Gmail's feature shows information about about recent activity, whether it's from a browser or an email client, and it's only limited to Gmail. Google's new recent activity feature shows "security-related actions you've taken, like signing in to your Google Account, changing your password, or adding a recovery email address or phone number. This information is for your entire Google Account, so sign-ins from any Google product (such as Blogger, Gmail, or YouTube) will be listed in this section."

There's a subtle difference: "A sign-in is only listed when you've actually typed your username and password to sign in. For example, if you've been signed in to your account for several weeks on your phone, checking your email from time to time, we'll only list the time and location of your initial sign-in." That's not the case for Gmail's account activity feature, which is not limited to the initial sign-ins.

In other related news, Google has a new security dashboard that shows information about your password, recovery options, notifications for unusual activity, 2-step verification and connected applications/sites.


{ Thanks, Florian K. and Herin. }

Baca Selengkapnya ....
Trik SEO Terbaru support Online Shop Baju Wanita - Original design by Bamz | Copyright of android kindle.