Kiran Malvi

Hey. Hi. So, I'm Kiran Malvi. So most of my details are on my resume. Apart from that, I have, like, 7 plus years of experience developing Android applications, in which 5 plus years of experience is specifically in the EMV domain. I have developed an application for Android POS, which was certified for Visa, Mastercard, and the contact and contact list both. I have extensive experience in Android development, creating memory-efficient applications, and working with different kinds of hardware integrations. In my Fintech journey, I have also worked on UPI applications and AAPS-based integrations, etc. So I do have expertise in that area. Apart from that, in my current job, I'm developing mostly kiosk applications based on Android for different hardware. This also includes different hardware integration, wherein I have to develop an application for Android, with barcode scanners, printers, cash drawers, etc. In this, I have in-depth knowledge of Kotlin integration and creating memory-efficient applications for custom hardware. These hardware tend to work on less memory. So I do have an eye for creating memory-efficient applications that have a better user experience, a smoother UI, and also tend to give fewer issues than other implementations. Thank you.

To make sure processing EMV transactions in the right way for PCI compliance, we need to ensure there is no major non-compliance, which PCI has is to prevent unsecured data processing from happening. There is no confidential data, such as user names, account numbers, CVV, etc., and EMV details are stored inside the device in a secure location, not even in logs. We also cannot store the actual card numbers and everything. We have to process data in a certain environment, where for PIN integration, there must be an encryption process, which should implement the UKPT implementation for PIN or master-slave integration, before processing the data. Also, we need to ensure in most scenarios, the data is in a particular format before uploading or storing it into local memory or uploading it to the host. So, these precautions need to be taken for processing payment transactions in a secure manner to be PCI compliant.

Very nice questions. So to apply secure cryptography communications between an Android POS app and its back end services, first of all, I would implement an ISO 8583 implementation of network calls instead of doing it by any other protocol like XML or JSON. ISO 8583 is widely used in POS environments, and it is specifically designed for post transactions, which ensures that all data types are sent in the correct format. To apply cryptography, we would use different mechanisms, including the encryption of PIN and card details, such as user PIN, card PIN, and encryption of card numbers, etc. For that, we would use the UKBT process, which is derived from a unique key per transaction. In this process, each device has its own private key and public key shared over the HSM to the host, and then before sending any transaction, that key is updated by incrementing its value and a unique encryption key is applied for each transaction. We would also ensure that the PIN is encrypted with a different key and card details are encrypted with another key. There are also different types of encryption mechanisms, such as master-slave mechanisms, etc. And to ensure data integrity, we use Mac solutions in the process as well.

Okay, so to update the cryptographic keys in post, transaction, is a very interesting thing, right. So, if we are using DUKPT, which is derived unique keyboard transaction process for that, we need to make sure that those keys are loaded from the factory itself. In which, what happens is, there is one master device in the factory, which has all the master keys. And then it, with the RSA encryption, it makes sure to pass on that per device. It will share the different public key to initiate with, which is known as IPEC. And IPEC key is unique per device and based on IPEC and there is a transaction counter stored inside the device. Based on these two combinations, a new transaction key is generated for each transaction, making sure that each transaction has a different key. So, these transfers, first of all, the direct pay transfer once in the factory, most of the time in a secure area, where there is PCI compliance, stating how that secure area should be and what are the standards for those. Also, there are standards set for transferring the key from the master device to the slave device. Also, there has to be a secure HSM hardware secure model, which generates and distributes these keys. So, this is the way we generally do the DUKPT, cryptographic key transfer. And also for the master-slave process, we need to use a secure area provided in a PCI-compliant environment to transfer the master keys.

This is a very interesting question again, wherein large-scale BOSS apple applications are concerned. 1st of all, there comes the application integrity issue, wherein if we are certifying the application for the AME environment, then once we are certified, any application should not have any changes inside that application. So we need to make sure that those modules are separate and completely different. And we only certify the modules that do the transactions separately, while other modules like UI and other user experience model modules should be separated out. When we speak about dependency injection inside this large-scale POS application, there are different ways to do that. Manual dependency injection is one way, but we can also use different kinds of libraries to do the dependency injection, like Dagger. The HID library, which is popularly used in the Android environment, can also be used to do this dependency injection. It makes sure that the application can be divided into different modules at the same time. It works in a very particular manner, the way we want. And for testing also, it becomes very easy to write test cases for applications developed using these libraries, such as Dagger or Hilt.

This is a very, like, the best way to say this is using the ISO 853 standards for pause applications wherein, it makes sure that communication is happening over TCP channel. And these are very lightweight packets, which contain 4 generally, these have the 128 fields. But these 128 fields are mostly used for the communication between the host and the bank or the acquirer. But for the POS application to be host, generally, we do use 64 of these fields only. And out of this, also, we use only some of those, like field 35 d. Data element 35 is majorly used to send user's card details. The data element 55 is used to send the EMV data, and data element 52 is used to send the pin data. Like this, the ISO 853 is a defined standard using which we can do a resource efficient network communication.

So the encrypted data is okay. The issue in this is, the key is defined as a need vector 123 in this, which is a compromise issue because we have defined the key inside the code base. And if the code base is compromised, it is difficult to change this key. And that's why, this is not a safe way to implement this.

So this is not a good way because there can be different types of errors when we're seeing exception errors. So there can be multiple issues. And if we're handling it only in one block, stating it as an unknown error will be very difficult to analyze those issues in the field. Because if any error comes up, we will just define that error as a generic one, which is not a good way to implement things. Ideally, we should be using different error codes and error values while logging these details so that it is very easy to catch what was or what went wrong with a particular transaction. I'll see if I can find anything else. So, I'll execute the transaction name request. We are waiting for a response, and the response is yes. This is what I can think of right now.

So, a mechanism to adapt to multiple payment schemes in an Android POS system is very interesting. First of all, there are EMV standards defined per acquirer. For example, Visa has different standards, Mastercard has different ones, GroupPay has different ones, and MX has its own standards defined. When we are certifying for any particular scheme, there are certain criteria that we have to meet. And once we do the certification, we cannot make any change in that particular model because that complete model is certified. Even if you make one-line change, although there are definitions, they have that this is a minor change, a major change, or only a case of major change. We need to do certifications. However, it's not safe or good practice to do all modules in a single module. That's why we need to modularize this flow as much as possible. Whenever we need to adapt a new payment scheme, we can just create a different module and take help of the common functionalities from the other modules, and then create a complete flow based on that module. So that we can certify that module separately. And once it's certified, it can have its own checksum for the verification and validation of that model. If there are any further changes done on that particular model, it's very easily identifiable. And in those cases, we can go for recertification based on the standards.

So if you're referring to a bottleneck in transaction processing, it depends on what you're referring to. Generally, the Android POS only processes one transaction at a time. It's not a back-end service where multiple transactions come at a time. But if you're saying there are bottlenecks with the POS, then we mostly narrow down the reasons based on the system's behavior. We'll also need to implement different types of logins so it's easy to identify where the issue is. There can be various scenarios where the issue is in network processing, where multiple TCP tunnels are open and not closed correctly, which can cause an overload of network and delayed network responses. Ultimately, closing all the TCP tunnels at the same time means not being able to connect to the host at all. Network bottlenecks can be identified and fixed by closing the network tunnels, like this is one of the scenarios. If there are bottlenecks due to storage issues or device issues, we need to identify those independently based on the device's behavior. And those can be addressed depending on what the issue is. If it's a memory consumption issue, we need to see if there are any memory leaks happening on that particular device or application based on some issue. If it's an encryption issue, which can be if the particular device has exhausted the number of keys, which is highly unlikely but can happen in certain scenarios. In those cases, we need to send that device to the factory to reinitialize the keys, etc.

I have not worked much on the Linux kernel part of the post terminal, but I am aware that there can be different kinds of parameters inside the Linux kernel because, essentially, these are very lightweight kernels. And, these do the EMV L2 certified kernels. So, these give us different kinds of parameters based on, like, what kind of PIN it supports, what kind of encryption that a kernel supports. These all can be parameterized differently.

So, again, I have not worked much on the Linux side or the POS system. I have mostly worked on the Android Java-based applications. But in this case, for better memory management, we need to make sure there are no memory leaks happening inside the system and whatever operations we are doing, we are closing.