Showing posts with label Mobile. Show all posts
Showing posts with label Mobile. Show all posts

Tuesday, 5 May 2015

Kernel mein (as in hindi) Kernel

Dear Reader,

I've backlogged quite a bit on my blogs and hope to complete them in the next couple of weeks. Every time I sit to complete a blog, I'm flooded with topics for a new blog!! This blog is technical and addresses issues in data security.

I will be updating this blog later with some code snippets and samples. But until then, I've only penned my thoughts.

Let me know what you think in the comments section.

Regards,
Jyothin

-----------------------------------------------------------------------------------------------------------------

Introduction

Mobile device security is getting the much needed push by technologist to provide a secure mobile experience to users. Whether it is financial transactions, personal data security, photo security, device security, protection from viruses, etc., it is imperative that one thinks about how secure their lives are with mobile devices becoming extensions of an individuals personality.

There are numerous ways in which a device can be made secure; DaaS (Desktop as a Service), ACL (Access Control Lists), encrypted data transmission, etc. and some of them go that extra mile to ensure device security; double encryption, remote wipes and auto-locks, mobile ID authentication mechanisms, isolated special subnets for mobiles, signal range control, etc.

The Probability of 'Safe'-keeping

In a non digital scenario, when an average person wants to safe keep items that are dear to them, the most likely way to do it is to install a safe in their house and secure it with a password or number lock. Sounds fine and work pretty well in most cases. Lets call this safe the outer safe.

Lets for a moment assume that the probability of someone breaking into the safe and stealing your items is x. Hence the probability of someone accessing your data is x.

Lets also assume that, you feel that x is not small enough for you. So you decide to put another mini-safe within the outer safe and also secure it with a password or number lock or any other better locking mechanism. Lets call this mini-safe the inner safe. Now the probability of someone stealing your outer safe is still x but the probability of someone accessing your data is not x.

Assume again that the probability of someone managing to break open the inner safe is y. By theory of probability the probability of someone accessing your items is x times y.

With only an outer safe:
P[break opening the safe] = x
P[accessing your items] = x

With an inner safe inside the outer safe:
P[break opening the outer safe] = x
P[break opening the inner safe] = y
P[accessing your items] = x * y

For any values you choose for x and y; P[accessing your items], when there is an inner safe is less than P[accessing your items] when there is only an outer safe.

For example, if x = 0.5 and y = 0.5,
With only an outer safe:
P[break opening the safe] = 0.5
P[accessing your items]   = 0.5

With an inner safe inside the outer safe:
P[break opening the outer safe] = 0.5
P[break opening the inner safe] = 0.5
P[accessing your items]         = 0.5 * 0.5 = 0.25

What's a 'Safe' in the Digital World?

A safe is an fixed sized enclosed space that stores your items and requires a key to unlock. In the digital world your items are data (bytes of information) stored in a fixed sized memory and a safe would be a means of protecting that memory space.

In operating systems, especially operating systems based on the Linux kernel, a user typically runs processes/tasks or reads/writes to memory in user space. The operating system itself runs in protected mode in kernel space. A user requests the operating system for access to resources in kernel space. Resources could be I/O devices, protected memory space, processor resources, etc. Requests are usually made using drivers which in turn use IOCTLs to provide custom functionality.

A user cannot access kernel space resources directly. So, in a way, one can think of everything in kernel space as being put in a safe (the outer safe) and access is restricted to users who have the root password OR via drivers. If there are no drivers then the only way to access resources in the safe is by the root.

For the purposes of this discussion, lets assume the resource we are interested in accessing is data in a fixed sized memory space in kernel space. Using the same idea described in the previous section if we can install an inner safe within the outer safe, in this case a kernel within a kernel, the probability of accessing data within the inner kernel is reduced and hence a means of increased security for the data. A protected mode within a protected mode!!

Of course, we would need a means of accessing the inner safe from the outer safe by means of a driver. In a mobile device, everything is stored as bytes of data and drivers can be loaded/unloaded as required thus adding another layer of security. Further, there is nothing stopping the driver from 'loading' the inner kernel at run-time. So the driver only loads the inner kernel with required, accesses the protected data in the inner kernel and shuts it down when done. The inner kernel is modified for every modify/write of data into its protected memory. So, in affect the inner safe does not exist unless it is required to access the data!

It should be possible to create multiple such independent inner safes to protect different items and load them at run time.

Isn't virtualization the same thing?

No. Simplistically put virtualization techniques typically allow one to virtualize hardware resources in order to run different operating systems on the same hardware so that, you can install and run different software applications on the same hardware and hardware resources, and everything is managed by the virtualization environment.

The aim of a kernel within a kernel is to provide an added level of security to data which is already running in protected mode.

Can I put another Safe inside the Inner Safe?

Sure you can, but the marginal advantage of having more than two safes would eventually diminish to 0 unless the locking mechanism at each inner safe is completely different from the other safes. Essentially making it difficult for anyone to break open each safe (as the locking mechanism at each safe is different).

READ vs. READ, MODIFY, WRITE

Breaking into an inner safe will allow one to read the contents of the inner safe. Modifying the contents is a totally different activity. However, once read the data is compromised. In case of an inner kernel, breaking into an inner kernel will potentially allow one to read the contents of its protected memory, modify it and write back. READ-MODIFY-WRITE, is easier in the digital world.

Moreover, creating the inner kernel would require one to hard-code certain kernel data that is unique to that version of the inner kernel and also ensure that that uniqueness persists even when the kernel is shutdown.

An Inner Safe cannot be duplicated but an Inner Kernel can...

Hmm... I guess it can.

Conclusion

I'm no expert on data security nor on Linux Kernel Internals and unless I make an attempt to write a driver to access an internal kernel, the intricacies and challenges involved in implementing it are beyond my own understanding.

If you are really paranoid about securing your data, take a space flight to the moon, find an undisclosed uninhabited area, dig a hole, bury it, and don't tell anyone.

Sunday, 17 August 2014

Mobile banking.... literally

Dear Reader,

Way back in 2007 when I was in the middle of my MBA, I came across a B-School case contest by the magazine Smart Manager. The contest challenged managers to solve a very specific business/managerial problem. In this particular case, it was about outlining a business expansion plan of the retail banking firm of a large bank. While researching more about retail banking itself, one bank's (Royal Bank of Scotland) historical method of bringing banking to communities stood out (see the links below... you should be able to get more links by Googling 'Mobile branch banking').


Although RBS probably had different reasons to provide such a service back then, it seemed like an ideal way to expand banking services to customers and communities as a whole, for the case in question. Back in 2007, I felt this would be a good method for business expansion. However, the contest judges didn't seem to think so.

Nevertheless, years later the service continues to grow in Scotland and has also gone high-tech...
and they even publish a schedule of stops...

So, what could be some of the challenges that existing banks in India may face to launch mobile branch banking?

We've never done anything even remotely close to it...
Actually, you do. Most banks send cash strapped vans to ATMs around the city/town to stock the ATMs with cash. This is pretty much the same thing, just needs to go that extra mile.

We can't send branches to rural communities, what if the van is attacked and all the money is stolen?
Get the van insured, use bullet proof glass, keep the cash balance low, square off the cash balance when it gets high, plaster large blown up posters of your CEO's face on the sides of the van, and show videos of your CEO sashaying down a ramp in the fashion show or giving a भाषण on a news channel debate. Don't forget to put the video in an infinite loop and full volume for maximum affect... that will surely drive away the vandals.

None of my employees want to go on the roadshow...
Put them on a rotating shift with perhaps a once a fortnight roadshow duty. Make sure they also work at the nearest branch and are accompanied by a teller and an IT guy. One of them can also double up as an automobile mechanic and the other can double up as the van driver! Also, can the van be air-conditioned? and maybe have a small refrigerator to store food and even have a porta-porta-potty?

We can't afford iPads in vans... we don't even have them in our branch offices!
Sure... don't use iPads but make sure you have a good reliable network connection to sync up transactions and other data so that you don't lose any of it. Maybe having a Pico base station will do the trick.

We have invested heavily in true mobile banking, and are more-ons to a smartphone app, so why waste resources on mobile branches?
A smartphone app has its place... no doubt about that but not everyone has a smart phone. Also, to install an app, YOUR customer needs to first have Internet access, download a compatible app, and install it. Why not get your IT guy to install a compatible version of the mobile app in YOUR customers' phone when they actually visit the mobile branch. The IT guy could also trouble shoot any issues and help them understand how to use the mobile app even after the mobile branch has left their locality.

We don't have good road access to all rural areas and communities?
Humph...

I don't like the idea....
?

Easier said than done...
Absolutely. I guess that's why mobile branches have not found much traction in India. 


All said and done, at the end of the day a commoner may feel that you come in a fancy van, do the dance and just run away with their money! One can never say.

Regards,
Jyothin