Sidhant Rajora

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

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

How would you apply? Yeah. Similar to, uh, what discussed earlier, we can use, uh, the whole conversation and the whole communication between, uh, and a a boss app and a back end service would be to use HTTPS. So everything gets, uh, transferred, uh, getting encrypted before before getting before leaving the device. Uh, and, uh, on top of it, we can have SSL pinning using some certificates. Yeah. That would be the that's that's kind of a standard, uh, process to do it.

To ensure, uh, PCI compliance, none of the data related to payment, related 2 tokens and anything. Nothing should be saved onto the device itself. And, uh, as soon as the transaction is done, only So I remember seeing some, uh, randomized token based among transactions and to identify the card detail. So these these tokens are kind of Uh, issued for transactions, but not did not belong to a particular card. So these transaction IDs and token numbers can be just saved, and every transaction can have its own token number to identify basically, a a generate a generated number that can identify a transaction, and the transaction can be linked to to a a guest ID or a profile. But, uh, to be, uh, PCI compliant, we should not save any data related to payment, Payment cards, uh, which involves, uh, guest information, card number, the the CVV number, expiry, and nothing of that sort. Uh, in India, there's been a concept, uh, tokenization that's been introduced by the Reserve Bank of India in which these cards can be saved, Uh, by the merchant or anyone, but not the exit details. But they can save that token that is being issued per app, And, uh, they can as, uh, again, just without having to input any CVV or any detail, they can just use this token to kind of initiate a transaction. But, yeah, in that case, OTP has to come and the guest has to put in an OTP, and then, uh, the guest can move their transaction. But yeah. So these tokens can, uh, be deleted by the guest at any point of time. But yeah. So to move away from, uh, the whole hassle of saving the card number, expiry, and everything, This is an initiative that's taken by the government of India? Yeah. But that's something that uh

It only requires a few features for processing loyalty points with the Android Boss. I'm gonna walk through the steps of secure implementation. Yep. So from, uh, the point of, uh, I would like to explain it, uh, in a few phases where, Uh, points generation to consumption is something which is like a transaction for me. So let's say, uh, a guest performs a transaction. And based upon transaction, a few percentage of, uh, loyalty points are assigned to the a a particular guest. So this acts like a money. So this, uh, so whenever done, uh, another transition getting processed, these token these, uh, loyalty points can be again redeemed, and the price will be reduced further based upon what, uh, a point Kind of values. So considering that fact so let's say we want to end of so a transition was made. Uh, certain points were assigned. So these points can only have can only so the same design would be whenever you are trying to redeem this particular, uh, points then your transaction, a secure OTP can be sent to the to the device where The guest has to enter the OTP, and then the transition can be, uh, later on confirmed. And once it's confirmed, then, Uh, 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, uh, there's a pause app in which, uh, I am at the at a store, and, uh, 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, uh, onto the POS machine. And I can say, okay. The transition is approved and authorized. And, uh, however, uh, how many points have been reading will be part of our messaging. Another thing that I can do is, Uh, but that pause app, I can have a different app, which is on my device. Whenever, uh, something is getting transacted from my wallet or my points, I'll get a notification saying that, okay, uh, uh, 4.50 rupees or 4.50 points are, uh, loyalty points are to be deducted from your account. Uh, please approve it. So it will be similar to, like, uh, what Google does. Whenever you log in to a Gmail or any other app, uh, 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, uh, technically authorizes them to kind of validate, okay, this is you who are trying to log in to the their system. So, similarly, we can have that particular mechanism in which these points and everything is just a part of, uh, like, a, uh, a CFO, which is being, uh, 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 OTP will be generated on time, not they cannot be generated before and after. So these, uh, trans these, uh, OTPs will be generated at the point of for transaction and, uh, the point of sales machine where the transition is being about to start. So as soon as, uh, as soon as I am added or I come onto the machine And, uh, I am just going in and asking for, like, okay. These are the problems that I need. Uh, maybe please, uh, just use my points. And once the The guy onto the other side of the POS machine can just, uh, fetch in your details account details by a phone number or mobile device or email ID. They can probably get into your okay. How many points you have? Uh

But to be honest, uh, like, sensitive information should not be saved on the local device. Even if, uh, that would be the my, uh, first recommendation that do not save that payment information onto the lower device other than keep it on to the server. But if it's the case that, okay, there are some data that's, So maybe a secure data that has to be set up and stored into your database storage. So maybe, uh, we can use storage, uh, security databases in which, uh, all the transactions, all the data that's being stored onto the device, all gets encrypted. And, uh, now the challenge comes in. Okay. How do we decrypt this data? So decryption can be based upon multiple, uh, things. First thing can be, like, a fingerprint ID can be used in to kind of decrypt it. And, uh, this becomes the master key for that particular data. And once fingerprint matches, you are free to kind of, uh, decrypted and get the data back. Similarly, if you have, uh, so whenever, uh, let's say, this is an encrypted data and you need a key to kind of validate whether it's So the correct key or, uh, not to proceed with the transaction. You can always show that on show the encrypted data, which would not matter. So 2nd step would be to, uh, lock it with some the randomly generated key, which is stored in, uh, the device itself. But its private key is sick, uh, is, uh, safely secured over some some server. So whenever, like, that data is needed, the private key is fetched Using some, uh, certificate valid verifications or maybe, uh, some, uh, SSL certificates. Uh, if that, uh, origin is, uh, and the source of app is kind of, uh, certified, and it's SSH key. So whatever the SSH SSH key we have on the app, it matches with the server. It will be ready to in the private key because based on the private key, you're gonna dig up the data and maybe you go with go about it. Or yeah. That seems like the the way that I would go about it.

Simply analyze the code block from a simulated EMV transition and a c plus plus pause application. Explain the potential issues that might, uh, arise with the error handling mechanism in v try is request valid through 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 a and then error. Returned response. The response was so So the first thing is that the object was never got created. So even if I for for the sake of understanding it, okay, let's say that object was created and, uh, we have this, uh, the response object all set. Uh, the problem is, uh, we will never get to know what went wrong with that request. So what was wrong with that request? And it may require us for, uh, for it for us to log it into our system so that it can be later on verified. Okay? For what reasons that request failed? That that would be the first thing that I would see here that, okay, you are trying and, uh, if request if not request 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, uh, whenever the request returns Boolean, and, uh, it might check for something, which is related to the request. And, uh, we probably pass in some metadata about what products 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 so same as with the catch all exception handler. So if we, uh, catch all the exceptions all at once, it just, uh, we cannot have a specific messaging related to it. And, uh, so maybe, like, uh, instead of catching all exceptions, we should be catching, like, exceptions based upon what kind of accident it could be. And based upon which error handling and, uh, uh, responding 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, be catching specific errors. And, uh, later on, uh, nontransactional related errors, maybe legal state exception or out of memory exceptions or whatever exception other than, uh, transaction related exceptions that we already, uh, like, uh, have a state machine with so we can probably, like, catch all of them together, but all the transition related, uh, should be cached, uh, in separate catch box so that proper message can be formed out of it. And later on, when we have to debug and see it, we know that, okay, for what reasons that, uh, exception was raised in.

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

To be honest, I haven't Explored, like, uh, profiling seamless apps at all, uh, that too in a linear based payment terminal system. So I have seen some, uh, payment systems that are, like, a number of these GUIs that, uh, with the airports and everything, I guess. But, uh, how will I go about it? And I'm I'm just, uh, like, guessing I'm guessing it a bit. I guess, uh, there should be some debugger which gets attached to a running c plus module in which, uh, that debugger may end up showing us memory consumption, memory locations, garbage collections, and all that stuff. So in c plus plus, what happens is, If you have, like, uh, mobile located and manually and, uh, you have to do analog and free and all that stuff. And, uh, if, Uh, all is being taken care of dynamically, and you don't dynamic of your location, and you are not worried about it. But still, there will be some memory leaks that we can surely look into, uh, based upon, uh, some sort of profiling with the debugger. Yeah. That's, like, that's my guess. I'm not so sure if it's, uh, if it is going to be the best answer, but, yeah, that's what I think of it.

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