Kiran Malvi

Hey. Hi. So, uh, I'm Kiran Malvi. Uh, so most of my details are on my resume. Apart from that, I have, uh, like, 7 plus years of experience developing Android applications in which 5 plus years of experience is specifically in EMV domain wherein I have developed an application for Android POS, which was certified for Visa, Mastercard, The contact and contact list both. Uh, I have extensive experience in Android developing, uh, creating a memory efficient application, but working with different kind of hardware integrations because, uh, in my Fintech journey, I have also worked on UPI application, AAPS based integrations, etcetera. So I do have, uh, expertise in that area. Apart from that, in my recent job where I'm currently working. Uh, here, I'm developing mostly the kiosk applications based on Android for different hardwares. And, uh, this also includes different hardware integration wherein I have to develop an application for, Uh, Android, uh, Android tablet with, uh, barcode scanners, printers, cash drawers, etcetera. And in this, I have, uh, in deep knowledge of Kotlin integration and as well as creating memory efficient application for, uh, the custom hardwares because these hardwares are tend to I'm sorry. I'm getting just yeah. Uh, these hardware certain to work on less lesser memory. So I do have, uh, an eye for creating memory efficient application which have Better user experience, smoother UI, and also, uh, tend to give lot less issues than the other, uh, implementations. Thank you.

Uh, to, uh, to make sure, uh, that processing EMV transactions in the right way for PCI compliance, we need to make sure there is no, uh, the major implement, uh, major compliance, which PCI has is to make sure there is no unsecured data processing happens. There is no, uh, like, uh, confidential data, like users, span number, uh, CVV, etcetera, and EMV EMV details are stored inside the device anywhere for any, any insecure location, even though for logs in logs also, we cannot store the actual card numbers and everything. Uh, they have to, uh, we processed in certain environment wherein, uh, wherein, uh, like, for PIN integration, there has to be a process, uh, encryption process, which is, uh, which should implement the the UKPT implementation for, uh, PIN or master slave integration, uh, before processing the data. Also we also need to make sure in most of the scenarios, which is, uh, the data should go in particular format to the before uploading or storing, uh, into the local memory or uploading it to the host. So these all precautions we need to take care, uh, for processing payment transaction in secure manner to be PCI

Very nice questions. So to apply secure cryptography communications between Android POS app and its back end services, uh, first of all, I would, uh, implement ISO 85 three implementation of network calls instead of, uh, doing it of, uh, by any other protocol like XML or JSON. Uh, ISO 8583 because, uh, it is, uh, widely used in POS environment. And then it is at the at the same time, it is, uh, specifically as it it is specifically for post, uh, transactions, it does make sure that all data types are sent correctly incorrect format. The way we want, uh, to apply cryptography, we do use different mechanism wherein, uh, the measure is encryption of PIN and card details, uh, like a user PIN, card PIN, and encryption of card numbers, etcetera. For that, we do use, uh, I have majorly used the UKBT process, uh, which is derived unique key per transaction. In this process, we do, uh, so, uh, each device has its own private key and public case shared over the HSM to the host, and then before sending, uh, before any transaction, that key is updated by 1, its values updated by 1 and each for each transaction, we basically make sure that unique encryption key is applied for each transaction. And in that also, we make sure that PIN is encrypted with different key and card details are encrypted with another key. Also, there are different types of encryption mechanism, like master slave, uh, mechanism, etcetera. And, uh, to make sure the data integrity, we use the Mac solutions in the bid process as well.

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

This is very interesting, uh, question again, wherein for large scale BOSS apple, uh, applications. 1st of all, uh, there, there comes the application integrity issue wherein, uh, if we are, uh, like certifying the application for the AME environment, then once we are certified any application, there shouldn't be any changes inside that application. So we need to make sure that those modules are separately, completely different. And we only certify the modules, which do the transaction separately and other modules like UI and other user experiences model modules should be separated out. Uh, when we say, uh, speak about dependency injection inside this large scale POS application, uh, we, uh, there are different ways to do that, wherein manual dependency injection is the way, uh, but we can also use different kind of libraries to do the dependency injection like Dagger. Also HID library, which is popularly used in Android environment can be used to do this dependency injection. And it makes sure that, uh, that application can be divided in 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 the test cases for, uh, applications who which have developed using these libraries, Dagger or Hilt.

Uh, this is a very, uh, uh, like the best way to say this is using the ISO 853 standards for pause applications wherein, uh, it makes sure that communication is happening over TCP channel. Uh, and these are very lightweight, uh, packets, which has, uh, which contains 4 generally, uh, these have the, uh, 128 fields. But, uh, these 128 fields are mostly used all 128 most of the 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, uh, generally, we do use 64 of these fields only. And out of this, also, we use only some of those, like, uh, field 35 d. Uh, data element 35 is, uh, majorly used to send user's card card details. The data element 55 is, uh, you send to, uh, used to send the EMV data, and data element 52 is used to send the, uh, pin data. Like this, uh, the ISO 853 is a defined standard using which we can do a resource efficient network communication

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

So this is not a good way because there can be different type of errors when we are seeing the, exception errors. So there can be multiple issues. And if we are handling it only in 1 block, Uh, and stating it as unknown error. It'll 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, uh, while while logging these details so that, It is very easy to catch what was or what went wrong with particular transaction. I'll see if I can find anything else. So execute transaction name request. We are waiting for a response, and the response is Yeah. This is what I can think of right now.

Uh, okay. So, uh, a mechanism to adapt to multiple payment schemes in Android POS system. This is very interesting one again. So, Uh, first of all, uh, there are EMV standards defined per acquirer. Like, Visa has different standards. Mastercard has different. GroupPay has different. MX and every acquirer has their own standards defined. Uh, and when we are certifying for any particular scheme, Uh, that time there are certain criterias that we have to meet. And once we do the certification, we cannot change, make any change in that particular model because that complete model is certified. And even if you make one liner change although there are the definitions, Uh, they have that this is minor change, major change, or only case of major change, we need to do certifications. But still, it's not safe to Or good practice to do all modules in single, uh, like all schemes in a single module. That's why we need to modularize this flow as much as possible. And whenever we need to adapt a new payment scheme, uh, we can just create a different module and Take help of the common, uh, 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, uh, for the verification and validation of that model. Uh, so if there are any further more changes done on that particular model, it's very, uh, easily identifiable. And in those cases, we can go for recertification based on the standards.

So if you're, uh, it depends that, uh, what you're referring to bottleneck in transaction processing, uh, because generally, the Android POS only, uh, process 1 transaction at a time. It's not a back end service wherein multiple transactions will come at a time. But if you are saying if, uh, POS is having any bottlenecks, then we mostly, uh, the reasons, uh, can be narrowed down based on the behavior of the system. Uh, we will also be, uh, we will also need to implement different type of logins so that it is easy to identify, uh, where the issue is. And, uh, there there can be various scenarios wherein the issue can be in, uh, network processing wherein, multiple TCP tunnels are open and if not closed correctly, then they might have the overload of network, uh, which can cause, uh, delayed network responses and ultimately, uh, closing all the TCP tunnels at the same time, so not able to connect communicate to the host at all, so, uh, network, uh, network bottlenecks can be identified and fixed by closing the network tunnels, like, this is one of the scenario. If there are any bottlenecks due to, uh, like, storage issues or device issues, we need to identify those independently based on the behavior of the device. And those can be addressed, uh, depending on what issue is. If it is a memory higher memory consumption issue, then we need to see if there are any, memory leaks happening on that particular device or application based because of some issue or, uh, if it is an encryption issue, which is, uh, which can be if, uh, that particular device has exhausted the number of, uh, keys, which is highly unlikely, but it can happen in certain scenarios. In those cases, we need to send that device to the factory to, uh, reinitialize the keys, etcetera.

I have not worked much on the Linux kernel part of the post terminal, but I am aware that there can be different kind of parameters inside the Linux kernel because, essentially, these are very lightweight kernels. Uh, and, uh, these do this does do the these are the EMV l two certified these these should be EMV l two certified kernels. So, Uh, these gives us the different kind of parameters based on, uh, like, PIN has the different parameters. What kind of PIN it supports? What kind of encryption that a kernel supports? These all can be parameterized in different

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