I am working on MasterCard Acquisition project using emv Module 6.2. I can successfully generate 1st Ac and retrieve tags from it properly but i am asked to include also the result of the 2nd AC in my ICC data before transmission to the issuer.
How can i generate the 2nd AC and include it in my field 55?
There looks to be some misunderstanding in what you need. can you explain the complete context. Below is how you deal in ideal environment.
In first generate AC
if you get ARQC you send it online to issuer.
If you receive TC you approve the transaction offline.
If it is AAC you decline offline.
Now assume you get ARQC and you are not able to go online, you check default action codes and if allowed you request for TC in second generate. If you get TC your transaction is approved offline, else you get AAC and transaction is declined!!!
---------------------05-Dec-2016-----------------------
Ok then i guess this is what you are looking for. CVR Byte 1 Bit 8 will tell whether second generate AC was requested or not. In an online transaction(after 1st Gen AC) this will be 1.Can you check what is it that you are sending now ?. Check the image for more information.
Now you may not need action codes but fyi, you have three types of action codes. denial (to decline the transaction offline), online( to send transactions to issuer), default( to decide on how to proceed when online was opted but unable to. There are two sets of action codes - Terminal( which is used in terminal action analysis) and issuer( which is used by card action analysis). download emv books here to read more.
Btw, are you doing M-TIP ?
Related
I have Suricata setup as HIDS on a couple of lab instances, and wrote some sample rules to alert on custom User-Headers and internal IPs I can easily trigger for purpose of teaching someone how to use Suricata.
For an advanced use case, I want to output the EVE JSON file somewhere downstream for eventual data analytics and BI use cases.
For that purpose, I want to drop the "noise" from EVE, or have a way for the fast.log to be output in JSON.
For instance, this is what I would consider "noise" as I want to just see triggered
,"event_type":"stats","stats":{"uptime":168,"capture":{"kernel_packets":313,"kernel_drops":0,"errors":0},"decoder":{"pkts":313,"bytes":68519,"invalid":0,"ipv4":305,"ipv6":0,"ethernet":313,"r$
{"timestamp":"2019-08-13T14:29:09.058698+0000","event_type":"stats","stats":{"uptime":176,"capture":{"kernel_packets":313,"kernel_drops":0,"errors":0},"decoder":{"pkts":313,"bytes":68519,"invalid":0,"ipv4":305,"ipv6":0,"ethernet":313,"r$
{"timestamp":"2019-08-13T14:29:17.059944+0000","event_type":"stats","stats":{"uptime":184,"capture":{"kernel_packets":313,"kernel_drops":0,"errors":0},"decoder":{"pkts":313,"bytes":68519,"invalid":0,"ipv4":305,"ipv6":0,"ethernet":313,"r$
I would only want to see stuff like this from fast.log
[**] [1:200002:6] ET USER_AGENTS Suspicious User Agent (BlackSun) [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP}
So is there a way to get only the Alerts in EVE, or a way to transform Fast.log into JSON?
Found an answer for myself again.
On Line 60 in the YAML, there is a value you can set to "No" for stats - that will eliminate probably 80% of the noise you have. You can go further an eliminate metadata for DNS, TLS, TCP, HTTP, etc. to further reduce your log file if needed.
I would like to get sample Issuer Script Template 1(Tag 71) or Issuer Script Template 2(Tag 72) value for testing the Kernel Application.
Thanks for the help....
In order that not just anyone pass some issuer script to a card and change its counters, SMI Secure messaging for Integrity( to make sure the data is not altered) and SMC - Secure messaging for confidentiality (to make sure none other can read) is used. Read EMV Book 2 Section 9
Secure Messaging for this.
Once you are done with this part, you can check Book 3 on what script you need to pass to the card.
This is packed in a Template 71 or 72 for the below reason.
Issuer scripts with tag '71' shall be processed prior to issuing the
final GENERATE AC command.
Issuer scripts with tag '72' shall be processed after issuing the
final GENERATE AC command.
Since this involves a MAC( based on your SMI Session Key) and a Cryptogram( based on SMC Session Key), I don't think a sample would help.
I am new to EMV development. My question is regarding Tag 91 (Issuer Authetication Data) which is sent by Issuer in EMV response. In my case, when tag 91 is missing in response packet then chip card decides to decline the transaction even if issuer has approved transaction online. So I am wondering whether Tag 91 is a mandatory tag which needs to be sent by issuer each time it approves a transaction online and what is industry wide understanding about it. Please let me know thoughts on it.
Also, In my case, Application Interchange Profile Byte 1, Bit 3 = 1 which means external authentication is required.
Are you working for Card Application or Terminal Application ?
Issuer authentication always have to be performed unless you are doing a partial chip implementation. I am sure you know that it is an additional level of security that ensures that the response came from the correct issuer.
When AIP B1B3 is on, it means card will expect tag 91.
In some cases it is even default. eg. D-PAS( Diners/Discover) AIP B1B3 is off, since it does not support External Authenticate. It is verified during second Gen AC. In such cases if the issuer wants card to not decline the transaction when ARPC not present, in the ACO( Application configuration Option), it is explicitly mentioned about partial chip implementation.
Check each payment scheme card and terminal specifications manual careful before you implement, as any loop holes in implementation may help a fraudster skip the security you wish to provide.Thumb rule, if you get ARPC from issuer, always sent it to card. Let the card decide.
From Card Application side I can add that "Application Interchange Profile Byte 1, Bit 3 = 1 means external authentication is supported, but not required. What does it mean ? Card may support Issuer Authentication, but may not required it for online transaction (issuer authentication can be mandatory or optional in card internal parameters). I.e. for optional it would be great to do auth, but if not - no problem, do online. And if Issuer have not sent tag 91 card may aprove transaction.
I'm in IT support. We have two types of correspondence:
With final users. The usual external communication with them.
With service providers (DBA, etc) Internal communication that can't be seen for the requestors.
For the first one, we use the 'answer to requestor'.
For the service providers, we use a comment and send CC to the service provider. But when they reply, RT considers their reply as correspondence and execute the actions for the 'correspondence' condition.
Then, when i wanna customize the scrips, RT doesn't distinguish between the actions: an email to the user and a replay from the provider (internal CC) are both "on correspondence" for RT, and send them both to the requestor.
I don't realize how to configure RT for send 1 y 2 to different actions.
Have I configurated something wrong? Which must I consider?
Or must I use a custom user scrip?
Thanks a lot!
RT should do what you are expecting, which is send correspondence (replies) to the requestor and send comments only to staff. There are two areas to look at to sort out why this isn't happening:
1) By default, RT's notification scrips use the Cc role to add another requestor. If you want to add a "commenter," you want to use the AdminCc role rather than Cc. This is likely the problem.
2) If that doesn't fix it, make sure you have two email addresses set up, one for correspondence and one for comment, something like support#example.com (correspond address) and support-comment#example.com (comment address). Then make sure you have your /etc/aliases file set up to route correspond with --action correspond and comment with --action comment. An initial example is provided in step 10 in the RT README.
I am trying the post an invoice to SAP using the F-47 transaction and using SHDB to record the transaction and learn how it works. I see there that sometimes BU and ZK BDC OK codes are used. I would like to understand the difference between them, but could not find any official documentation. Please, explain the difference between the two?
I found the meaning of some of the status codes. I post it here, so I can remember:
/00. Enter
/AB Go to overview
=ZK Go to additional information
=ENTE Enter (don't know exactly what is difference between /00)
=PI select cursor location
=STER Go to taxes
=DELZ delete cursor
=GO continue
=BU post (save)
/EEND end processing
=Yes select "yes" from message box
=BP park (save)
=ENTR Enter (don't know exactly what is difference between =ENTE or /00)
=AE save when changing document
=BK change document header (parking or posting parked document)
=P+ next page
=BL delete parked document
A BDC_OKCODE indicates which action is (will) be executed on a screen (things like save, back, exit etc). The BU code is used for a SAVE function (like in MM01 transaction). Sorry but I cannot recall to which function ZK maps to. Obviously their difference lies in the fact that they map to different functions. You can still find out which function each button utilizes by using System->Status->GUI status.
By the way, BTCI transactions are not fully robust- minor changes in GUI flow let your program break. Error handling / analysis is tedious.... DId you have a look to posting methods more preferably? E.g. like BAPI_* function modules? With the help of LSMW you can browse for different input methods and use them later standalone. Or you can use transaction BAPI directly.