Chandrika | 18 Jun 2013 15:52
Picon

Google certificate upgrade to 2048 bit keys

Does the version of CA list in ICS 4.0.4 meet the requirement when Google changes the certificate and the issuing CA chain to  use 2048 bit keys?

Thanks,
Chandrika

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Elvine Kemunto | 18 Jun 2013 11:34
Picon

trace my phone

 my phone got lost a month ago i didn't put any security because i was still new with the phone how can i trace it i registered it with the email address am using write away and i have managed to download some google apps to it though i don't have it.or either lock it so that no else uses it

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Robert Dailey | 17 Jun 2013 20:09
Picon

MITM attacks on Gmail?

Is it possible for MITM to occur for traffic on the Android Gmail client when connected to a Wifi network? If so, how can I verify whether or not my SSL certificate has been compromised for Gmail?

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
F. Duchene | 14 Jun 2013 23:01

[android-security-discuss] *GreHack 2013* — 3rd Call For Papers - November 15, Grenoble, France

---------------------------
*GreHack 2013* — 3rd Call For Papers
November 15, Grenoble, France
http://grehack.org — Twitter: <at> grehack
---------------------------
*Topics*
The 2nd International Symposium on Grey-Hat Hacking — aka GreHack 2013 — will gather researchers and practitioners from academia, industry, and government to discuss new advances in computer and information security research.

All topics related to vulnerability discovery are within scope. In addition, topics of interest also include but are not limited to:

 - Reverse Engineering and Obfuscation
 - Vulnerability Discovery, Analysis and Exploit Automation
 - Embedded Systems Security, including Smartphone Security
 - Hardware Vulnerabilities
 - Malware Creation, Analysis and Prevention
 - Web Application Security
 - Network Exfiltration
 - Intrusion Detection and Prevention
 - Security and Privacy in Cloud, P2P Networks
 - Penetration Testing
 - Disclosure and Ethics
 - Digital Forensics
 - Applied Cryptography and Cryptanalysis

We encourage original and groundbreaking submissions, demonstrations, release of a new open source/non-commercial tool, and interaction with the audience.
Each submission will be reviewed by at least three members of the Program Committee.

---------------------------
*Important Dates*
 - Submission deadline:         June 30, 2013 11pm59  Honolulu, Hawaii Time
 - Reviews due:                 August 25, 2013 11pm59 Honolulu, Hawaii Time
 - Decision notification:       September 4, 2013
 - Final paper camera-ready:    September 30, 2013 11pm59 Honolulu, Hawaii Time
 - Symposium:                   November 15, 2013 

---------------------------
*Submissions Types*
GreHack 2013 will consider following types of submissions:
    *Full research papers* presenting mature and novel research results. Their total length should range from 10 to 16 pages.
    *Short Papers/Extended Abstracts* describing novel ideas of potential interest to the security research community. Their total length should range from 4 to 8 pages. 
    
    Papers accepted by the Program Committee will be presented at GreHack 2013. Each paper must include an abstract and a list of keywords, be formatted in a single-column format, use at least 11-point fonts, and have reasonable margins. Templates are available on the website (Latex and Word). Total length includes the bibliography and any appendices.
    GreHack does not require anonymized submissions, thus authors and affiliations must be mentioned. For accepted papers, at least one of the authors must attend the conference and present the paper. Papers must neither have been previously accepted for publication nor submitted in another conference or journal with formal proceedings. Industry conferences such as BlackHat do not have formal proceedings.

Further questions on the submission process may be sent to the program chairs at pc-chairs-2013 <AT> grehack.org.

---------------------------
* Best Paper Award*
The Program Committee members will select the best paper to be announced and awarded at the last session of the symposium.

---------------------------
*Publishing: Springer JCVHT*
The best papers will be selected from submissions, carefully reviewed, and published in the prestigious Springer Journal in Computer Virology and Hacking Techniques (JCVHT).
JCVHT is an open journal: the access to the papers is free of charges for the reader.
 http://www.springer.com/computer/journal/11416
 http://academic.research.microsoft.com/Journal/890/journal-in-computer-virology

---------------------------
*Program Committee*
 - Dan Alloun (Intel, Israel)
 - Ruo Ando (NICT, Japan)
 - Jean-Philippe Aumasson (Kudelski Security, Switzerland)
 - Sofia Bekrar (VUPEN Security, France)
 - Elie Bursztein (Google, US)
 - Fabrice Desclaux aka Serpilliere (France)
 - Adam Doupe (UCSB, US)
 - Fabien Duchene (LIG, France)
 - Chris Eng (Veracode, US)
 - Peter Van Eeckhoutte aka corelanc0d3r (Corelan, Belgium)
 - Manuel Egele (CMU, US)
 - Philippe Elbaz-Vincent (UJF, France)
 - Eric Filiol (ESIEA, France)
 - The Grugq (Thailand)
 - Mario Heiderich (Ruhr University Bochum, Germany)
 - Pascal Lafourcade (VERIMAG, France)
 - Cedric Lauradoux (INRIA, France)
 - Pascal Malterre (CEA-DAM, France)
 - Laurent Mounier (VERIMAG, France)
 - Stefano Di Paola (Minded Security, Italia)
 - Marie-Laure Potet (VERIMAG, France)
 - Paul Rascagneres aka r00tBSD (Malware.Lu, Luxembourg)
 - Sanjay Rawat (India)
 - Raphael Rigo (ANSSI, France)
 - Nicolas Ruff (EADS Innovation Works, France)
 - Steven Seeley aka Mr_Me (Immunity, US)
 - Fermin J. Serna (Google, US)
 - Nikita Tarakanov (Russia)

---------------------------
*Accepted Author Benefits* (1 author per accepted paper)
 - One free entry to the conference
 - Limited financial participation to author expenses (accommodation and travel). Priority for travel grants will be given to students.

---------------------------
*Submission Guidelines*
Submissions will be handled via EasyChair at:
https://www.easychair.org/conferences/?conf=grehack2013
In the unlikely case that the submission website would be unavailable,
you can email your submission to: pc-chairs-2013 <AT> grehack.org.


--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Rex Ching | 14 Jun 2013 19:01
Favicon

AOSP Keystore RSA signing implementation security issue

Hi there


I am developing the secured key storage for one of my mobile device running JB422, found out that the default keystore signing and verifying API always force the device using the following options
    params.digest_type = DIGEST_NONE;
    params.padding_type = PADDING_NONE;

That says we have to sign the data with a RSA private key without padding, and during verification, we have to use the raw mode to verify data
That sounds to be a known security issue of not using PADDING in signature processes

Several places all talk about the potential vulnerabilities 


Wonder if any security experts can comment if I am wrong or right? Appreciate with your help!


Thanks
Rex

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Rex Ching | 14 Jun 2013 02:55
Favicon

Android KeyStore Security issues in Signature implementation

Dear Android security experts


I am a device developer working on a secured storage implementation on a JB422 device.
I got a concern on a signature verificaiton vulnerability in the reference implementation of Android's keystore daemon
Here is the code details:
static ResponseCode sign(KeyStore* keyStore, int sock, uid_t uid, Value* keyName, Value* data,
......
.....
    params.digest_type = DIGEST_NONE;
    params.padding_type = PADDING_NONE;

The function would use the private RSA key from keystore to sign the incoming data with NO PADDING option. This seems to be a well known vulnerability to hackers if they can control the input (meaning if they root device and can control the call the sign() API calls in keystore)


Wonder if any security experts from Android team can comment on this implementation and if agreed, how we can fix that ?

Thanks
Rex

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
DMSR | 13 Jun 2013 14:34
Picon

Security issue over certificates pinning in JB 4.2.


Hi all,

I am going to implement Certificates pinning in JB 4.2.
For that I am broadcasting the intent android.intent.action.UPDATE_PINS so that  the CertPinInstallReceiver.java  will create and write the
data into the file /data/misc/keychain/pins.

My question where will be the security .If i pin the certificates by using above concept after some time some other malicious app will have the ability to overwrite with some fake pins or overwrite with it's specific pins so that what ever i have pinned are lost.

Please clarify my question related to security.

Thanks ,
DMSR

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
seattleandrew | 13 Jun 2013 17:43
Picon

OEMs & Carriers are ruining the security model of Android

Hey guys, just wanted to open up discussion on something I think a few of us recognized but didn't know the scope of how large it was.

Quarks Lab just released a vulnerability breakdown for Samsung phones in which they created applications with little to no permissions and were able to basically exploit the entire system. How did they accomplish this? Read here for more: http://www.quarkslab.com/dl/Android-OEM-applications-insecurity-and-backdoors-without-permission.pdf

"I'm a busy person, I have no time to read this!"

Fine... tl;dr Samsung's built-in apps (i.e. the non-stock apps Samsung bundles in) allow any application installed on the device to leverage their permissions, content providers, etc. Thus leaving a huge gap in the Android security model. In other words, I can create an app that appears to have no permissions, but rather uses the permissions from apps already installed on the device.

Juicy stuff: From one application, they found a vulnerability that allowed them to write and execute code... essentially getting access to whatever they wanted.

Okay, so what's up with my sensationalist title-- As security researchers, professionals, enthusiasts, what can we do about this? For users I imagine flashing a custom ROM or sticking with a Nexus device would suffice, but what about government and corporate implications?

One of the biggest issues for me have been the speed at which Android updates to other devices, often referred to as fragmentation. In this case I think the groups largely responsible for delaying security patches are the carriers. This is because some of them take months/years to deploy patches and updates and by then, exploits will have been in the while for a long time. Can carriers be held responsible for willingly delaying security patches to their customers devices? Even if the intentions are good, e.g. "we want to retain a high QA standard that's associated with our brand." I can't help but feel we need a different update model for these mobile connected devices.

Why aren't Security updates completely separate from Usability updates? Thoughts?

/end rant

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Jeffrey Walton | 11 Jun 2013 05:00
Picon

Previously Unknown Exploits?

Hi All,

Reading through [1], it mentions a couple of previously unknown exploits.

Does anyone know anything about them (other than the article calling
them "Android operating system")? Do they stem from the kernel? Or are
they taking advantage of some linxml2 bugs (or equivalent)?

Jeff

[1] https://www.securelist.com/en/blog/8106/The_most_sophisticated_Android_Trojan

--

-- 
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Hariom Gupta | 7 Jun 2013 19:25
Picon

Restrict folder to copy


Is there any way to restrict a folder to copy using USB connectivity.

I need a solution to protect a folder to copy from phone to phone or phone to windows via USB or bluetooth etc.

Kindly do the needful.

Thanks
Hariom Gupta

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Malik Bougacha | 7 Jun 2013 10:37
Picon

Issue with the eap-ttls certificate

There seems to be a big issue with the implementation of EAP-TTLS in its actual form. The list of certificate seems to be empty. It is therefore pretty hard for an user to select the proper tls certificate. 

Nonetheless, It is mandatory, for the proper implementation of tls, that the CA of the certificate is checked. It let every single android phone vulnerable to a MITM. 
What can the community do about this ? Or what can I do about this ?

--
You received this message because you are subscribed to the Google Groups "Android Security Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscribe <at> googlegroups.com.
To post to this group, send email to android-security-discuss <at> googlegroups.com.
Visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Gmane