I am working on EMV technology and looking for the communication ( Request/Response) between terminal and issuer for authorization / online pin checking.
I know Offline data authentication check on terminal only and then terminal send data to issuer. I wonder what data need to send for authorization process.
I know little bit about DE elements ( like DE-55 element - contain data like Amount,Authorised(Numeric) ,Amount,Other(Numeric),ApplicationCryptogram(AC)).
Could anybody give me a link/documnent where I can see what and how communication in what format happening between Terminal and issuer for authorization (cryptogram validation) , Online PIN checking , CVV validation
and all.
sorry for my bad english.
Terminal communicates only with the acquirer. The communication between terminal and acquirer is determined by acquirer host system like Compass+, OpenWay, other and specific implementation you can ask your host provider (easier to ask the Bank for which the terminal will be the point of sale ). In common this all protocols are based on ISO8583, so you could read there. Also some information you can find at EMV Book 4, 12 Acquirer Interface.
EMV Book 4:
An authorisation message shall be used when transactions are batch
data captured. A financial transaction message shall be used when
online data capture is performed by the acquirer. An offline advice
shall be conveyed within batch data capture when supported. An online
advice or a reversal message shall be transmitted real-time, similarly
to an authorisation or financial transaction message.
Issuer does a couple of things
1. Validate the card, for example status, expiry date, PIN etc
2. Validate account, eg. account status, available funds, transaction type allowed on the account etc.
3. Validate the authenticity of the card by veriying the ARQC
4. Generate ARPC to let card know that the issuer is genuine.
5. Send post issuance operation using issuer scripts.
You may be mostly sending the data in ISO8583 in case you are using a POS or NDC+/D912 standards in case you are using ATMs.
PIN is sent as PIN Block encrypted under Terminal PIN key.
If host is the issuer it can do HSM command DC and verify the PIN. See the HSM documentation for the format and expected data.
CVV is a part of the track and verification happens with HSM command CY. Expiry date is available from track. Service code is also available but make sure it is the service code for iCVV.
Now considering the above requirements, I can say the following data are required to be sent to host.
Message type
PAN
Pcode
Amount
Local date and Time
Trace
expiry data (not mandatory in case you are sending track data)
POS entry code
PAN Sequence number
Track2
terminal id
Merchant ID
Acquirer Currency Code
Chip Data which includes
All tags used in CDOL1( this would be sufficient for your HSM command KQ/KX)
ARQ Cryptogram
PIN block in case online PIN is selected CVM
Try with this and let me know in case anything more is required.
Related
I'm playing around with Chainlink's "Register an Upkeep using your own deployed contract" example: https://docs.chain.link/docs/chainlink-keepers/register-upkeep/#register-an-upkeep-using-your-own-deployed-contract
However, once the UpkeepIDConsumerExample is deployed with the Link Token Contact, Registry and Registrar parameters for the respective chain, I am unable to use the UpkeepIDConsumerExample.registerAndPredictID function as it fails.
(Gas estimation errored with the following message (see below). The transaction execution will likely fail. Do you want to force sending?
Internal JSON-RPC error. { "code": -32000, "message": "execution reverted" })
I've tried on Rinkeby, Mumbai and Polygon Mainnet, incase testnets weren't live yet. And I've used the parameters suggested by the docs for calling the function. And I have sufficient Link in my metamask.
Is it correct to use these: https://docs.chain.link/docs/link-token-contracts/ as the Link Token Interfrace parameter?
Thanks!
I was able to make this work (though I tried only on Goerli)using the code from the offical docs that you linked to.
For the benefit of others that read this post, I will break it down into detailed steps - perhaps more than you needed for an answer!
Prerequisites
Get some LINK tokens in your browser wallet
Deploy a Chainlink Keepers-compatible contract -- this is your Upkeep contract; the one that will be automated. Here is the example Upkeep smart contract that you can copy and deploy right away. You can use 10 as the interval -- that's 10 seconds. This way you can see the upkeep happen fast. Note this Upkeep's address
Next, deploy the UpkeepIDConsumerExample from the example in the docs, which is the smart contract that programmatically registers your Upkeep Contract. This contract handles registering the Upkeep Contract you deployed in Step #2 with Chainlink's Keepers network, so that the Keepers Network can automate the running of functions in your Upkeep contract. Note this Contracts Address
Making it work
From your wallet, which should now have LINK in it, send 5 LINK to the deployed UpkeepIDConsumerExample address. This is funding it will need to send onwards to your Upkeep (Upkeeps need funding so they can pay the Keepers Network for the compute work they do in performing the automations).
Using Remix, connect to the right network and then connect to your deployed UpkeepIDConsumerExample contract by using its address.
When Remix shows your contract and its interactions in the DEPLOYED CONTRACTS section of the UI, fill in the parameters for the registerAndPredictID() function using this table in the docs.
While following the table referred to above, please note:
upkeepContract is the Upkeep Contracts address - the one you deployed in Step 2 in Prerequisites
gasLimit - I used 3000000
adminAddress - this can just be your wallet address. The one that you're deployed from, sending LINK from etc.
Amount - 5 LINK expressed in Juels (LINK's equivalent of Wei), so 5000000000000000000
Sender - this is the UpkeepIDConsumerExample's address. In this example it's the calling contract itself.
run registerAndPredictID() with the params as per the previous step. It should run successfully.
Verify by going to the Keepers App and checking under "My Upkeeps" for a new Upkeep that you just programmatically created.
Cleanup
In the Keepers App note the LINK balance of the Upkeep you just created and funded with the 5 LINK -- it may be a bit less than the 5 LINK you sent it because the keepers network may have already run your Upkeep - we had set the interval for 10 seconds in Step 2 of Prerequisites.
And on Etherscan check whether UpkeepIDConsumerExample has any
LINK in it (it shouldn't because the 5 LINK you sent from your wallet to this contract, was transferred when you ran registerAndPredictID() and sent an amount of 5 LINK
Hope this helps!
How to use security in SD synchronization without GAM?
I need to block unwanted connections. How can I validate the execution of
Synchronization.Send () and Synchronization.Receive ()
I can not use GAM because I have to adapt my application to a pre existing security system.
There is currently no way for sending additional parameters or HTTP headers in the requests, so you'll need other means to identify your user.
One thing you could do, is call a procedure before synchronizing, passing the relevant information to identify the user (an authorization token or something like that). Then, you should validate that the next call is to the synchronization process, and check for instance that the IP address and the "device id" are the same.
Where would you validate the user's information, depends on which synchronization are we talking about.
For the Receive operation, you may perform your validations in the Offline Database object's Start event.
For the Send operation, everything is saved to the database by using Business Components. So you may add your validations in all the BCs that are involved.
Note: having said all the above, it is highly recommended that you use GeneXus Access Manager (a.k.a. GAM), where all this is already solved.
Second note: you should use HTTPS in all your connections; otherwise, none of this will be secure.
Strange problem seen while querying a Cisco Call Manager via SNMP v3. SNMP v2 works fine.
When using get-next-request, the response is supposed to be a get-response, but from time to time I get a "report" response instead.
Reporting on an oid that's got nothing to do with the oid in the get-next-request.
Dump from wireshark could be provided if interesting. The oid in question is (phone update table):
1.3.6.1.4.1.9.9.156.1.2.4.0
Usually the response is a get-response with an oid similar to:
1.3.6.1.4.1.9.9.156.1.2.4.1.2.580
But every now and then the response is a "report" with oid:
1.3.6.1.6.3.15.1.1.2.0
My application (.net using sharpsnmplib) reads this as a regular get-response and get's all confused. SNMP v3 encryption and authorization seems to be all good. CUCM 10.5 and sharpsnmplib 7.6.
You will have to spend some time learning SNMP v3, so as to understand what is the "discovery" process and why REPORT message is important.
IdNotInTimeWindow is just the OID 1.3.6.1.6.3.15.1.1.2.0, which usually means the time stamp in your request is already out of time window.
Your code should carefully handle such REPORT messages (resend the request based on the new time stamp in this REPORT message), though I will agree that #SNMP Library should provide better support on that (it's coming, in the next release).
I'm planing to start some sms based application and currently in feasibility study part. In my application client have to sms their problem to the server and we have to analyse the problem and take reasonable action. Also We have to find the tentative location through which tower they have been connected. I have seen about silent sms feature but not understand. Is any body have experience on how to detect location of sms creator (not in android or iphone). Please help me on determining whether it is possible or not to find the location. If possible then how?
In short this is not possible.
an SMS message weather in PDU mode or text mode does not carry the information to match the source location to the message in any way shape or form.
With reference to the article you linked to in your opening post, I'm sorry to say that there's so much B$$l S$$t in that post that I can smell it from here.
In all the years Iv'e worked with GSM systems, both as a network maintenance engineer and later as a developer writing software to use these systems, not once have I heard of anything such as an 'LMU' or an 'E-OTD' in fact the only acronym that article really got correct was 'BTS' oh and the bit on passing the data over the signalling channel.
As for the silent SMS, well that part actually is true. The special type of SMS they refer to is actually called a Ping-SMS and it exists for exactly the same reason that a regular PING on a TCP/IP network exists, and that's to see if the remote system is alive and responding.
What it's NOT used for is the purpose outlined in the article, and that's for criminal gangs to send it to your phone and find out where you are.
For one, the ONLY people that can correctly send these messages are the telephone operator themselves. That's not to say that it's impossible to send one from a consumer device by directly programming a PDU if you have the necessary equipment and know how. You could for instance pull this stunt off using a normal GSM modem, a batch of AT commands and some serious bit twiddling.
However, since this message would by it's very nature have to go through your operators SMSC and most operators filter out anything from a subscriber connection that's not deemed regular consumer traffic, then there's a high chance this would fail.
You could if you had an account, also send this message using a web sms provider that allowed you to directly construct binary messages, but again they are likely to filter out anything not deemed consumer grade messages.
Finally, if you where to manage to send an SMS to a target device, the target device would not reply with anything anywhere near a chunk of location based info, cell tower, GPS or otherwise. The reason the SMS operators (and ultimately the law enforcement agencies know this info) is because EVERY handset that's attached to the GSM network MUST register itself in the operators MSC (Mobile switching centre), this registration (Known as ratching up) is required by the network so it can track what channels are in use by which device on which towers so that it knows where to send paging and signalling info.
Because of the way the PING SMS works it causes the destination device to re-register itself, usually forcing the MSC to do a location update on the handset which causes a re-registration.
Even then, all you get in the MSC is an identifier of the cell site the device is attached too, so unless you have a database in the organisation of all cell sites along with their exact lat/long co-ordinates, it's really not going to help you all that much.
As for the triangulation aspect, well for that to work you'd need to know at least 2 other transmitters that the device in question can see, and what's more you'd need that device to report that info back to someone inside the network.
Since typically it's only the Ril (Radio interface layer) on the device that actually keeps track of which transmitters it can see, and since the AT commands for many consumer grade GSM modems have the ability to query this information disabled, then it's often not easy to get that info without actually hacking the firmware in the device in question.
How does Google do it? well quite easy, they actually have commercial agreements with network providers that pass the details of registered towers to their back-end infrastructure, in the apps themselves, they have ways of getting the 'BSS List' and sending that list back to Google HQ, where it's cross referenced with the data from the network operator, and the info they have in their own very large transmitter database and finally all this is mashed together with some insane maths to get an approximate location.
Some GSM Modems and some Mobile phone handsets do have the required AT commands enabled to allow you to get this information easy, and if you can then match that information to your own database you can locate the handset your running from, but being able to send a special SMS to another device and get location info back is just a pipe dream nothing more, something like this is only going to work if your target device is already running some custom software that you can control, and if your device is running software that someone else is controlling, then you have bigger problems to worry about.
I'm just wondering how one could set this up without the BOSH dying. I have the sid, rid, and everything but I was wondering how long i could automatically log people on for the time of lets say a cookie and how is this achieved.
Your answer depends on how long it takes for your BOSH session to timeout. It's usually 60 seconds until it throws away the session.
Just a note- you probably do not want to automatically log in a user, since the proper XMPP flow is not done. Here's a typical flow:
-> Login and establish a BOSH session.
-> Send Presence
---> Server sends a <presence/> packet to all entities in your roster, notifying them that you are available.
---> Server sends a presence probe to all of the entities in your roster's server, getting their current availability.
<- Presence packets come raining down on your session.
-> Request roster items
<- Server sends you a list of items in your roster.
With the approach of using the same session, you skip all of this initialization, which I assume is important to your application, as you will not get presence of any entities until they change their presence. Sending another <presence/> stanza will not send you the current presence of everyone in your roster. So... if that isn't important to you, go ahead and do it. I'm just providing some useful information before you go and implement the thing and find out that there are caveats to your solution.
What worked for us was to use localStorage, and automatically log them in via a "Save my password" button. That makes it simpler and less work. Also, it can be confusing when a user reloads the page and they get logged back in automatically, versus a user closing the page and coming back in 5 minutes to be greeted by the login page. It's just plain confusing.
Good luck!
You can do one of the following as per your need and convenience:
Auto detect about user login status via cookies. Do an http-pre-bind and issue new rid/sid to the user. This will generally be transparent to user on your page.
Instead of issuing new "sid" on every page refresh/reload which can be quite expensive under high traffic, you can pool the underlying xmpp tcp streams. Next time when a user need sid/rid to start again, these can be fetched from the connection manager pooling the sessions.