How to resolve XCode's “valid signing identity not found” error

Generally, this error is caused because of a mismatch between a provisioning profile and a private key. It can also be that you even do not own a private key that makes your identity identified to the provisioning profile which are you working with.


First Resolution
Double-check that the profile that you have got from Apple Developer Program is the correct one that you are supposed to have. Sometimes organizations have multiple profiles for each team and although you have a correct private key, you own the wrong provisioning profile.

Second Resolution
You do not own the private key of the provisioning profile and/or identity that you are using. You need to own a private key file with .p12 extension in order for your identity to be validated. Whoever have created your identity (in case you work in a  team of developers, it could be someone else), has it on his/her machine when he has created the profile and/or identity. you need to get this key from that person or reissue a new private key (which takes some time) in order to resolve the issue.


If this sounds too confusing and does not make any sense for you, follow my step-to-step guide to How to sign your MacOSX application code with codesign?

How to sign your MacOSX application code with codesign?

A Brief Preface: I recently realized that the documentation for signing your Mac OSX applications with codesign is distributed across many documents which is extremely hard to find (You can find those documents in the "more to read" section of this post). Also, in the documentation it has been assumed that you will sign your code with XCode which is not always the case. As you may know, XCode is mainly used for development with Objective C for MacOSX and iPhone but a lot of Mac OSX applications are written in C/C++ and Java which XCode does not support any feature for those project types and makes the signing process extremely hard.

Now, let us start:

1. Go to Apple's Developer Program's Member Center. Go to member center. Write your credentials and enter.

NOTE: If you have not registered in Apple's Developer Program, you need to do so before you can sign your code.

2. Under Developer Program Resources, click on Certificates, Identifiers and Profiles. Under Mac Apps Click on Certificates. Then go to your certificate and then Click on Download. Now you have downloaded the Certificate.

3. Find the certificate file that you downloaded, and run it.
Keychain Access program will be opened by default and will put your Certificate under login keychains and certificates category:

4. Download your private key from the Apple's website: In the downloaded folder you will find a key file with .p12 extension which is Mac’s public key (PKCS12) format. Again, open the file and automatically it will be attached to the certificate you just downloaded.

Check whether it is already there as you expect it.

5. Next Step is to get Developer’s ID. Right click on the certificate of Mac developer profile which you want the code to be signed with and click on “Get info”. On the new windows, scroll down and get the SHA1 fingerprint of the certificate:

Remove the white-spaces and put it under $DEVELOPER_ID in your sign command or if you have one, in your build script. Also, you need to add the requirement for signing. Read about it on Mac Developer Documentation: Apple's Codesign Requirement Specification

Remark: One example of requirements can be of following (This example uses Mozilla's XULWrapper platform):

CODESIGN_REQUIREMENTS="=designated => anchor apple generic  and identifier \"org.webapp.xulwrapper\" and ((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or ( certificate 1[field.1.2.840.113635.100.6.2.6] exists and certificate leaf[field.1.2.840.113635.100.6.1.13] exists  and certificate leaf[subject.OU] = \"FOO123BAR1\" ))"

/usr/bin/codesign -s "$DEVELOPER_ID" -v \
   --requirements "$CODESIGN_REQUIREMENTS" \
   "$APPDIR"

6. You can sign the code now. Run the above command and you should be good to go.

Further References:

• Apple's Mac App Programming Guide Documentation
• Apple's Code Signing Guide

Android Attacks in a Nutshell (Part I)

1.1 Android and Dalvik

Android is an OS designed for smartphones. It includes a sandbox application execution environment, and a customized embedded Linux system that interacts with the phone hardware and an off-processor cellular radio. The Binder and application API runs on top of Linux. Each application is executed within a Dalvik Virtual Machine (DVM).

Applications interact with each other and the phone through different forms of IPC. Intents are typed interprocess messages that are directed to particular applications or systems services, or broadcast to applications subscribing to a particular intent type. Persistent content provider data stores are queried through SQL-like interfaces. Background services provide RPC and callback interfaces that applications use to trigger actions or access data. Finally, user interface activities receive named action signals from the system and other applications. DVM runs .dex files that are designed to be more compact and memory-efficient than Java class files. DVM fucntions close to Java Virtual Machine (JVM), with differences in application structure, register architecture, instruction set, constant pool structure, ambigous primitive types, null reference and comparison of object references. [4]

Figure 1: The Android System Architecture [4]

1.2 Android Security Mechanism
Shabtai et. al [2] categorizes Android’s security mechanisms into three main categories:
 • Linux Mechanism
 • POSIX users
 • File Access
 • Environment features
 • Memory management unit (MMU)
 • Type safety
 • Mobile carrier security features
 • Android-specific mechanisms
 • Application permissions
 • Component encapsulation
 • Signing applications
 • Dalvik virtual machine

One of the most crucial elements inside the previously mentioned list is the application permission mechanism. Generally, Android permissions are categorized into 3 security levels: Normal, Dangerous, and Signature. Normal permissions protect API calls that could annoy but not harm the user (e.g., SET_WALLPAPER); these do not require user approval. Dangerous permissions let an application perform harmful actions (e.g., RECORD_AUDIO). Signature permissions regulate access to extremely dangerous privileges, e.g., CLEAR_APP_USER_DATA.

 Depending on which OS functionalities an application wants to access, the developer has to define the permissions that his application requires. All permissions an applications needs are specified in the AndroidManifest.xml file, which is part of the every application package. Typical permissions comprise e.g. android.permission.INTERNET permission, which allows applications to open network connections. The permissions that were defined by the developer are shown to the user during the installation process of the application. Upon seeing them, the user can either decide to install the application and grant it all requested permissions, or he can abort the installation process. Permissions can neither be granted individually nor can they be granted or revoked at runtime. This process is also called install time permission grant system, which is the opposite of Time-of-Use permission systems as in Apple iOS. The user either accepts all requested permissions, or he cannot install the application. 

In this report two attacks are presented. First is a Cross-Site Scripting (XSS) attack against WebKit Web engine. The attack is classfied under minor-impact attacks with high rate of occurance. Seocond attack is a permission re-delegation which is an intersect of taxanomies 4 and 6, each of which have severe-impact with medium and high rate of occurance, reprectively. For more details on security factors in Android, see [2].