Sidhant Rajora

Hello, I'm Sudan. I live in India, and to be specific, I live in Rajasthan. So, it's been seven and a half years that I've been working in the software industry. Currently, I work with the ecommerce giant, Target Corporation. They have their stores and online deliveries and all. Like, the ecommerce related stuff happens in the United States of America. So, they have an office in Bangalore, and I work on their flagship mobile app. So, day-to-day my jobs include brainstorming with new features, ideas, UX inputs, building features, debugging, and keeping the stability up tight. Also, I have had a brief experience with mobile in the last couple of months, and along with this, I have worked with startups in my past, which were into ecommerce along with some medical related stuff. Yeah. That's pretty much related to my work background. I have completed my engineering from

So these cryptographic keys can be associated within a hardware-based key that can be added to a POS system, which takes in all the keys, and that will be the most bulletproof way to transfer the cryptography keys securely. If we cannot do that, then we can have SSL communication over an HTTPS. And then, those keys can be used by using RSA, only public keys can be transmitted. And based on those public keys, public-key private keys can be transmitted, and based on some public keys, they can be decrypted. And the data for getting the data back, we need to decrypt that data using the private key. So, we can use our mechanism to have those keys in it. And this whole conversation can happen on SSL and using TLS, and maybe we can use X.509 or some certificate using SSL pinning, which can be used to validate the certificates, and then those certificates can be further used to decrypt. And maybe, like, identify the owner of the keys and then send back to get decrypted via the private key, basically. So these are some ways that we can

How would you apply? Yeah. Similar to what was discussed earlier, we can use the whole conversation and the whole communication between the app and the backend service to use HTTPS. So everything gets transferred and gets encrypted before it leaves the device. And on top of it, we can have SSL pinning using some certificates. Yeah. That would be the standard process to do it.

To ensure PCI compliance, none of the data related to payment, related to tokens, and anything. Nothing should be saved onto the device itself. And as soon as the transaction is done, only the card details are replaced with randomized tokens to identify them. These tokens are issued for transactions but do not belong to a particular card. So, transaction IDs and token numbers can be saved, and every transaction can have its own token number to identify it, generating a number that can be linked to a guest ID or a profile. However, to be PCI compliant, we should not save any data related to payment cards, which involves guest information, card number, CVV number, expiry, and nothing of that sort. In India, there's a concept of tokenization introduced by the Reserve Bank of India, where cards can be saved by the merchant or anyone, but not the exit details. They can save the token that is being issued per app, and they can initiate a transaction without having to input any CVV or detail, just using the token. In that case, an OTP has to come, and the guest has to put it in, and then the guest can move the transaction. These tokens can be deleted by the guest at any point in time. To move away from the hassle of saving card numbers, expiry, and everything, this is an initiative taken by the government of India.

It only requires a few features for processing loyalty points with the Android Boss. I'm going to walk through the steps of secure implementation. So from the point of view where points generation to consumption is something like a transaction for me. So let's say a guest performs a transaction. And based upon the transaction, a few percentage of loyalty points are assigned to the particular guest. So this acts like money. So whenever done, another transition gets processed, these tokens, these loyalty points can be again redeemed, and the price will be reduced further based upon what a point kind of value is. So considering that fact, let's say we want to end a transaction was made. Certain points were assigned. So these points can only be used when you are trying to redeem this particular points then your transaction, a secure OTP can be sent to the device where the guest has to enter the OTP, and then the transaction can be later on confirmed. And once it's confirmed, then this transition guard goes into an authentic state or maybe in a slightly elevated state where because of this authorization, the points that have been assigned to me can be redeemed. First thing is that. Second thing is maybe we can have some sort of a way to let's say there's a pause app in which I am at the store, and I purchased something. Now I want to redeem my points. So probably I'll get a message. In that message, I get an OTP, and I can put it onto the POS machine. And I can say, okay, the transaction is approved and authorized. And however, how many points have been redeemed will be part of our messaging. Another thing that I can do is, but that pause app, I can have a different app, which is on my device. Whenever something is getting transacted from my wallet or my points, I'll get a notification saying that, okay, 4.50 rupees or 4.50 points are loyalty points are to be deducted from your account. Please approve it. So it will be similar to what Google does. Whenever you log in to a Gmail or any other app, it sends a notification by which you open up a view, which you have a possibility to check mark and cross or maybe just put it in some number, 55 or something like that. And once you add in that input that same number or you click on yes, it technically authorizes them to kind of validate, okay, this is you who are trying to log in to their system. So, similarly, we can have that particular mechanism in which these points and everything is just a part of a CFO, which is being secured by this particular net. Okay. Until and unless I'm not authorized with a valid OTP or a valid sequence number, I cannot execute the transaction further. And these OTPs will be generated on time. They cannot be generated before and after. So these OTPs will be generated at the point of transaction and the point of sales machine where the transaction is being processed. So as soon as I am added or I come onto the machine, and I am just going in and asking for, like, okay, these are the problems that I need. Maybe please, just use my points. And once the person on the other side of the POS machine can just fetch in your account details by a phone number or mobile device or email ID. They can probably get into your account and say, how many points you have.

But to be honest, like sensitive information should not be saved on the local device. Even if that would be my first recommendation, do not save that payment information on the local device, other than keep it on the server. But if it's the case that some data needs to be stored, maybe a secure data can be set up and stored in your database storage. So maybe we can use secure storage databases in which all the transactions, all the data being stored on the device, all gets encrypted. And the challenge comes in. Okay. How do we decrypt this data? So decryption can be based upon multiple things. First, a fingerprint ID can be used to decrypt it. And this becomes the master key for that particular data. Once fingerprint matches, you're free to decrypt and get the data back. Similarly, if you have encrypted data and need a key to validate whether it's the correct key or not to proceed with the transaction, you can always show the encrypted data, which wouldn't matter. The second step would be to lock it with a randomly generated key, which is stored in the device itself, but its private key is safely secured on a server. Whenever that data is needed, the private key is fetched using some certificate validation or maybe SSL certificates. If the origin is certified, and the app's source is certified, and it has an SSH key, and the SSH key on the app matches the server, it will be ready to access the private key. Because based on the private key, you're going to decrypt the data and proceed with it. That seems like the way I would go about it.

Simply analyze the code block from a simulated EMV transition and a C++ pause application. Explain the potential issues that might arise with the error handling mechanism in a try-catch block for a valid request through an ineligible exception. Respond to that error. There's a valid request. If it is not a valid request, it fails. More transition processing, catch this one. It had a transition build due to an 'and' then error. Returned response. The response was so. The first thing is that the object was never got created. So even if I for the sake of understanding it, okay, let's say that object was created and we have this, the response object all set. The problem is we will never get to know what went wrong with that request. So what was wrong with that request? And it may require us to log it into our system so that it can be later on verified. Okay? For what reasons that request failed? That would be the first thing that I would see here. You are trying and if the request is not valid, then just throw a legal request exception. But what was the reason for that request to be invalid? So that is something that we can pass through whenever the request returns Boolean, and it might check for something related to the request. And we probably pass in some metadata about what product is needed, and we can probably log it for our sake of understanding it later on when we try to fix it. Second thing is, yeah. So, same as with the catch-all exception handler. So if we catch all the exceptions all at once, we cannot have a specific messaging related to it. And so maybe instead of catching all exceptions, we should be catching exceptions based upon what kind of accident it could be. And based upon which error handling and responding back with the error would be very much clear to the machine's UI wherever the errors are shown. So instead of catching all the errors all at once, we should catch specific errors. And later on, non-transactional related errors, maybe a legal state exception or out of memory exceptions or whatever exception other than transaction-related exceptions that we already have a state machine with, so we can probably catch all of them together, but all the transition-related errors should be caught in separate catch blocks so that proper message can be formed out of it. And later on, when we have to debug and see it, we know that for what reasons that exception was raised.

Kotlin is introduced in another possibility when handling a credit card payment. I don't know the issue related to the cryptography that potentially exposes sensitive data. Encrypted data, card data. String cipher. Cipher.get instant easy. Okay. Inspect to buy a delay. So I see that the key is kinda publicly visible to us. That should not have been the case at first. And I guess the vector is also easily caseable, which makes it okay. Someone must have used any vector 1, 2, 3. So that's easily deductible, basically. So I can reduce it, and I can use it to decrypt it. And the key itself is not that hard to brute force. So first, we should not be using the plain text security spec. Other than that, we should have a random, randomized string maybe related to keys and maybe generated based on some random salt. And then it should be stored securely. And then whenever we need it, a server key must be used to decrypt that key. And then that key should have been passed instead of a display text string being passed there. And even the card data as a string. So we have the card data. And the encoded string is an encrypted string. So Cipher do final, card data to byte array. And Cipher is built on top of better specs, secret spec, and it's AES, CBC, and AES. So if we are going to do this with AES, then the only problems I see are an easily guessable vector spec and an easily usable secret key, which could have been part of some response from the server. Or maybe it could be a hardware bank key, which could be secured from those hardware itself rather than keeping it here directly. Or maybe it could be driven via an asset you have an Android app, which goes back to the server and asks for a secret key to decrypt data or maybe encrypted data. And once it's encrypted with the public key, so I cannot use RSA. So I just have to have used some strong secret key and vector spec, the initializing record for it. Once that's sorted, I guess this should work fine, in my opinion. And maybe we can use something called RSA. Maybe just get rid of everything. And we have a public key, so we encrypt all the data with the public key. Only then do we have the private key. So it wouldn't matter to anyone. So we can just use a very long number as a public key and then a randomized string maybe and use that as an RSA public key. And yeah, that seems like a way to go with. And this data can be stored back onto the server. And once we request the data back or the private keys with the server, they can return data back to us based on if the calling app or the calling system is identified by the server based on certificates.

To be honest, I haven't explored profiling seamless apps at all, like, that is, in a linear-based payment terminal system. So I have seen some payment systems that are, like, a number of GUIs that are used in airports and everything. But how will I go about it? I'm just guessing it a bit. I guess there should be some debugger that gets attached to a running C++ module, in which that debugger may show us memory consumption, memory locations, garbage collections, and all that stuff. In C++, what happens is, if you have manual memory management and you have to do alloc and free, and all that stuff. And if everything is being taken care of dynamically, and you don't have to worry about it. But still, there will be some memory leaks that we can surely look into based upon some sort of profiling with the debugger. Yeah, that's my guess. I'm not so sure if it's going to be the best answer, but yeah, that's what I think of it.

Was there to configure and optimize Linux kernel parameters for a dedicated person. Not special about it at all.