Creating two files to hold key pairs

Sometimes there is a need to use private/public key pair for authentication/verification. SSH and other secure command utilize a similar strategy.

Below steps create two files. The file called keystore.jks holds the private key that is used to sign a piece of data. They keystore.jks is a private file and should be secured. The file customer.jks contains the certificate-which wraps the corresponding public key.
The file customer.jks is public and can be used to verify the signature produced by using private key from keystore.jks.




1. Create a JKS file to hold the private key and certificate (which is wrapped public key)

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

2. Export the certificate from keystore file created in previous step with to a file called mydomain.crt

keytool -export -alias selfsigned -file mydomain.crt -keystore keystore.jks

3. Create a new JKS file to hold the certificate exported in previous step

keytool -genkey -keyalg RSA -alias blah -keystore customer.jks -storepass password -validity 360 -keysize 2048

4. Now import the exported certificate to the customer.jks

keytool -importcert -alias selfsigned -file mydomain.crt -keystore customer.jks

5. Verify that customer.jks contains certificate with alias selfsigned

keytool -list -v -keystore customer.jks

SSL failure with DSA certificate on ios

This may come handy testing ios > Remote server over SSL.

SSL connection from ios device to a remote server will fail, if the remote server's certificate's algorithm is DSA. I found this during testing and I don't know if Apple has this documented.

My remote server was a Java server, and used JKS as the keystore format. The Java Keytool by defaults creates DSA type certificates.

To test that having the RSA certificate will get me past the issue. I created a new self signed certificate with JDK keytool with RSA type certificate.  Than I converted the certificate to PEM format and ran openssl server with the PEM certificate. I then connected to the openssl server from the safari browser on the ios device and the connection was successful.

You may ask why didn't I directly create the certificate with openssl in the PEM format, well I used keytool to show a collegue how to convert JKS to PEM.

1. Create a self signed certificate
   keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
2. Export JKS to PKCS12
   
   keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12
3. Convert PKCS12 to PEM
   
   openssl pkcs12 -in keystore.p12 -out keystore.pem
4. Launch a test server with openssl command
   
   openssl s_server -cert keystore.pem -www
5. Connect to the server from a browser on iOS or from a remote device
   
   openssl s_client -connect  host:4433

Self signed Cert with Android and iPhone

Often there is a need to put a certificate on the android device (emulator | real)  for testing with SSL. This wil be the case when one needs to use a self signed cert since getting a real CA signed cert is expensive.

The high level steps are :

1. Export the cert  from your current keystore and put it into a file
2. Copy the cert file to android device
3. Run settings app to add it to the trusted certificates.

The caveat it that the exported file from step 1 needs to be in p12 format.

Here are the detailed steps for Android emulator and using the source keystore as JKS.

1. keytool -importkeystore -srckeystore -destkeystore -deststoretype PKCS12 -srcalias
2. Start the Android emulator - emulator -avd & - Wait for this to finish
3. adb - devices will list the android instances it know about, wait for the emulator to show up here as running.
4. adb push /sdcard/file.p12 - Copies the exported cert file to /sdcard area of Android
5. Go to Emulator > Settings > Security > Install Trusted Cert from SD card
6. Type the password that you specified in step 1
7. You should be good to go.

It is even easier for iPhone. 

1. Just email the cert from step 1 to an email configured on iphone as an attachment
2. Open the email from iPhone and click/tap the attachement. 

If you are going to fail, fail fast.

On my return flight from SFO earlier this month I read the “The Lean Startup” book. Its advice on short feedback loop, validated learning and pivot resonated with me. As I thought more about the topic I realized how a lot of teams that practice Scrum/Agile, follow it only for delivering the specified requirements.

What is not included in many teams Scrum/Agile loop are requirements. What if a product was delivered on time, with specified features and its quality was superb-and it was a failure. It doesn’t matter whether Scrum or Agile was used to deliver a product that didn’t have the features the market wanted.

We need to accept that Product Managers are fallible like everyone else.  Even with all the market research, competitive analysis, domain knowledge,  and out of the box thinking too many products fail. We need PMs to be challenged and assume that the specified requirements are wrong-until they are validated by Mr. Market.
In software testing we know the value of failing fast. Fail fast should also be applied to other aspects to business. With fail fast all requirements would be validated by Product Managers before they are actually built and delivered.

The challenge is how we get Mr. Market to validate requirements that won’t be released in another few years. That is a topic for another day-while I mull over it.

Five Security Enhancements to Android

Five Security Enhancements to Android.

Kudos to the Android security team for Bouncer.  Hopefully the below features are on your radar and will be delivered soon.

1. Many android app request permissions upon install. Here are a few permissions: being able to read your contact list, send sms or send text messages on your behalf, to reading network state . Often when I read the permissions an app requests , I question if it really needs a given permission. Often, I am tempted to grant the app only some of the permissions and deny other permissions. Alas, Android does not allow selective permission grants.  My only choice is to either not install the app or grant the app all the permissions it requested and suffer.

2. Stop malware infected apps from getting into the marketplace and run all the necessary security checks (white/blacklisting/heuristics) when an app is downloaded to a user's device. The android marketplace needs to further improve developer validation and further limit nefarious apps from getting into the marketplace. Stronger checks, audit and continual checks of the both the app and the developers will help. 

3. Simplify permissions: The model security model replies on Java security model and sandboxing. This model is not suitable for the problem at hand. The permissions encode the resource being protected and the action along with the permission name. The security permissions are runtime permissions are consequently developers don't write defensive code to deal with the scenario where the permissions are not granted to the app. They simply rely on the default runtime failure. With defensive programming, developers will gracefully code for the cases when the functionality is not available because of denied permissions. 

4. Make permissions grant one time and allow permission grants to expire. Often app request permissions that I am hesitant to grant. However I might be ok to grant that permission for the next 1/2 hour or just this once. Just like in real life, I should be able to grant permission just this once, and expire them.

5. App notifications: Many apps send notifications on updates. The app specific settings often include controls for these notifications. I have seen some apps where the control for app specific notification is either missing or inadequately offered in the app specific applications.  A feature to control all notifications, available as the top level android settings would be very useful.

  

While #5 isn't a security feature, I couldn't resist listing it here since it has been my bete noire of late.

There are clouds

When you look at the sky do you see a cloud? I bet more often than not you see clouds. And this precisely is the problem with many of the cloud providers. They exist in isolation, and often do not help companies deploying to multiple clouds solve many problems (especially in the security area) effectively.

Let’s take an example of a hypothetical XYZ Corporation. XYZ decides to leverage a few SaaS providers for its need in the area of Human Capital Management (HCM), Finance & Payroll, and Customer Relationship Management (CRM)-XYZ signs up with three different cloud based providers.

While all looks good on the surface, there are problems.

Let's walk down the triad of AAA (Authentication, Authorization, and Audit) issues with the above setup.

1. Authentication: Where is the source of Identity hosted? Is it hosted at XYZ or is it hosted at a Cloud Provider?
2. How does the cloud provider trust an external source of Identity
3. How does XYX securely provide its users/employees/contractor to the hosted cloud provider and continue to keep its users in sync with the cloud provider.

3. Since we are talking multiple SaaS providers, what if a user John Doe is represented in various ways in the SaaS provider’s identity store. Representation from jdoe, john.doe, and jodoe has all been in corporate LDAP for years. Now imagine trying to reconcile John Doe across SaaS providers.

Typically SaaS (Cloud) providers are not aware of other cloud providers and they can’t offer services that leverage other providers.

For example if there was a business need to ensure the principle of “separation of duties” continued to be enforced when the John Doe is a user in HCM and Finance & Payroll offered by different vendors. How does one ensure that the HCM and Payroll system do not allow John Doe to both change his pay grade (an HCM function) and release payment (a Finance and Payroll feature ) on his expenses.

The separation of clouds causes problems in Authorization and Audit too. For example how does one audit that John Doe did not access HCM function when a given CRM function was accessed.

There are a few ways to solve this problem:

1. If it hurts, don't it – don’t sign up with multiple cloud providers - just kidding.
2. Put a level of indirection, a service like apigee may help
3. Standardize – Cloud Interoperability standard under development and JavaEE 7 will help, but a lot more is needed.
4. Cloud vendors to externalize some of their data to allow third party reconciliation, audit, authorization checks etc.

This is a hard problem, none of the solutions are easy, without side effects, or will work for everyone.

Do you face this problem? What are other ways to address this issue? Is there any effort to address this issue?

Why Facebook's hacker way will change

http://www.msnbc.msn.com/id/46263927/ns/technology_and_science-tech_and_gadgets/t/facebook-hacker-way-way-life/

My take on this:

Hacking and moving fast is to facebook's advantage right now-no doubt. Hacking is ok, when there is little legacy code. Most interaction with FB services today is by humans, who are smart enough to deal with changes when the web interface changes.

As more machines(programs/automation) interact with FB and as it matures, FB will face the same inevitable slow down that other once fast growing companies have faced.

Comments, thoughts welcome.