I have successfully generated a ARQC by satisfying the PDOL required by the ICC. The ARQC required the following PDOL tags.
9F66 TTQ
9F02 Amount Authorised
5F2A Transaction Currency Code
9A Transaction Date
9F37 Unpredictable Number
The AID returned from ICC
06 01 11 03 A00000 0F83000000000000000000006975A844
The Cryptogram Version Number as above 17 (11 Hex)
My question, when I submit the transaction to the acquiring bank for authorisation via a ISO8583 host to host connection, in the ICC related data element do I only populate the EMV tags required by the PDOL and response Tags, or do I submit all ICC tags including for example the 'Terminal Verification Results' which was not required as per PDOL ?
Based on the CVN 17 the required fields to validate Cryptogram is
9F02 Amount
9F37 Unpredictable Number
9F36 ATC
9F10 CVR
Agree with comment from Michal.
Acquirer require much more EMV tags to transfer them to Card Issuer side and identify correct card profile and finally validate Cryptogram. The list of EMV data can be different in small details and place of these EMV Values transferred in ISO 8583 message. Refer to your Acquirer ISO 8583 specification.
The short summary of EMV tags and other fields required by Acquirer Interface you may see in EMV specification Book 4, Article "Authorisation Request".
Keep in mind that contactless cards, like your Visa PayWave may need to transfer own specific Tags depending of Card Brand Specification.
Unfortunately this is a question you should ask to your acquirer. The usual is that you populate all the data you have, especially because some of them may be used for risk management rather than cryptogram calculation. List of mandatory data elements is usually longer than what is required purely for cryptogram generation. Second thing is that your application should not interpret proprietary data elements like Issuer Application Data unless you are required (remember there are other card application specifications and you might have trouble differentiating them on the acceptance side). Side note - AID is not IAD, 9F10 is not CVR.
In most simple terms, what your card is doing here is generating a cryptogram based on elements in CDOL (elements, its order and size, will be mentioned in payment scheme docs for each CVN). So at the issuer end it should get the same elements to validate the cryptogram( and optionally to generate the response cryptogram ).
Related
I have successfully send ARQC to host, In response I have field 55 (ISO 8583) with different tagged data, I want to just clarify it by comparing it to sample field 55 response data. Can any one provide me sample response data of field 55 ?
In ISO8583 standard DE55 is allocated for EMV related data in request and response. In the response you can receive [ARPC][ARC] or [ARPC][CSU]. At times you can see template 71 or 72 which are issuer scripts with tag 9F18 optionally to identify the issuer script. Refer the payment scheme documentation for exact implementation details.
I am trying to understand the usage of SCP DEK in store data command.
As per GP Card spec 2.2.1- "The data encryption key (DEK) for decrypting sensitive data, e.g. secret or private keys. This key is a double length DES key and is used as a static key."
I requirement to encrypt the Store data APDU data. Now I have 3 questions
Is indeed SCP DEK used to encrypt EMV AUKs (Application Unique Keys) present in one of these store data commands?
If statement #1 is correct the which key is used to encrypt data field in the APDU?
Is the an indicator in commands prior to store data which says that data field in store data command would be Encrypted or NOT?
I would be able to set store data CLA, INS, P1 and P2 as per GP card 2.2.1 and Amendment D spec.
Asking this question here since crypto.stackexchange does not have global platform and cryptography tags
Any help is appreciated
Nevermind, I found answer
Yes
S-ENC Secure Channel Protocol '03' – Public Release v1.1.1
section 6.2.6 APDU Command C-MAC and C-DECRYPTION Generation and
Verification
External Authenticate command P1 as per 7.1.2.1 Reference Control Parameter P1 – Security Level - (Encrypted value =03 - C-DECRYPTION and C-MAC/ Clear value = 01 - C-MAC)
The first result from Google gave me an answer from 2012 so I wondered if there was a better one than 'use armoury' now?
It's fine if I have to decode the raw transactions, I would be grateful if someone could take me through the steps.
Thanks in advance :)
I'll answer my own question,
It was unbelievably easy.
(from the debug console or command line)
listunspent
produces a/the list of unspent outputs at your disposal.
Make a note of the 'txid', 'vout' and 'scriptPubKey' of each output you wish to use.
Use the 'createrawtransaction' command followed by a list of dictionaries containing the txid's and vout's of the inputs you chose earlier followed by the addresses you wish to send them to (the send to addresses are in a single dictionary, not a list of dictionaries).
createrawtransaction [{"txid":txid,"vout":n},...] {address:amount,...}
If you don't want to send the outputs in total (you want some change for yourself) you will need to include an address that you control in your sending dictionary (from your wallet or somewhere else) since outputs cannot be partially spent, sorry.
To pay the mining fee simply leave some of the total output amount unaccounted for and bitcoin will use it as the mining fee by default (fee is 0.0001 at time of writing).
If all went well you should be given a hex string.
Use the 'signrawtransaction' command to check there are no errors by passing in your new hex string followed by a list of dictionaries with the txid's, vout's and scriptPubKeys we got at the very beginning of all this.
signrawtransaction <hex string> [{"txid":txid,"vout":n,"scriptPubKey":hex},...]
note: in newer versions of bitcoin the list of dictionaries is not required
If you got a new hex with "complete" : true after it then all went well and you can now use the 'sendrawtransaction' command followed by the even newer hex you were just given to broadcast your newly created transaction into the bitcoin network.
sendrawtransaction <new hex string>
If you managed to sign it successfully but get a "code":-22,"message":"TX rejected" error please see the footnote below.
Notice it only took four commands in total:
*get (listunspent)
*create (createrawtransaction)
*sign (signrawtransaction)
*send (sendrawtransaction)
Easy :)
FOOTNOTE:
Be aware if you designate an unusually large fee like 0.5btc (I tried this on the testnet) the network will reject your transaction when you try to broadcast it because it thinks you've made a mistake which I discovered whilst I was experimenting.
(This is also the case if you are trying to spend more BTC than you have available.)
In the end I set the fee to 0.001 and it worked fine, here is a link to my question regarding this situation.
Another possibility is with Electrum. Under the Addresses tab right-click on one with non-zero balance and select 'Spend from'.
You have to click View > Show Addresses if you do not have the Addresses tab.
from where you wanna send your BTC. All you need to fill the withdrawal address of bitcoins. You may send your BTC to Bitfinex with the same process:
Fill withdraw address
Fill amount to be sent.
Verify your payment.
Done.
I sign document with PADES LTV Profile. Signer library is written base on Pdfbox library.
I have one problem.
In PADES LTV profile, the final revision must be checked in online (It means that OCSP responses, CRLS and certificates of this revision must not be in document secure store (DSS)).
For testing, I add 12 revision to my document.
Every time when I add new revision, I do not add certificates and ocsp responses of this current revision to the DSS. I add previous revisions certificates and ocsp responses to the DSS. I do this because last revision must be checked in online. So I must not add OCSP response of last revision to the DSS. I do so, but sometimes Adobe reader thinks that last revision have embedded OCSP response in the document.
The problem might be is that following:
Each ocsp response must be unique, even if when we generate them with the same certificate. In the other words, If we request ocsp object twice, they must be unique.
For this I do that following but it does not work:
private OCSPReq buildOcspRequest(X509Certificate issuerCert, BigInteger serialNumber, File inputDocument) {
InputStream is = new FileInputStream(inputDocument);
X509CertificateHolder certificateHolder;
certificateHolder = new X509CertificateHolder(issuerCert.getEncoded());
CertificateID id = new CertificateID(new BcDigestCalculatorProvider().get(CertificateID.HASH_SHA1), certificateHolder, serialNumber);
OCSPReqBuilder ocspReqBuilder = new OCSPReqBuilder();
ocspReqBuilder.addRequest(id);
DigestCalculatorProvider digestCalculatorProvider;
JcaDigestCalculatorProviderBuilder digestCalcProvBuilder = new JcaDigestCalculatorProviderBuilder().setProvider("BC");
digestCalculatorProvider = digestCalcProvBuilder.build();
// get SHA 256
DigestCalculator digest = digestCalculatorProvider.get(AlgorithmIdentifier.getInstance("2.16.840.1.101.3.4.2.1"));
OutputStream os = digest.getOutputStream();
IOUtils.copy(is, os);
byte[] messageImprint = digest.getDigest();
BigInteger time = BigInteger.valueOf(System.currentTimeMillis());
// time + imprint
byte[] nonce = ArrayUtils.addAll(time.toByteArray(), messageImprint);
Extension extension = new Extension(OCSPObjectIdentifiers.id_pkix_ocsp_nonce, true, nonce);
ocspReqBuilder.setRequestExtensions(new Extensions(extension));
return ocspReqBuilder.build();
}
this is testing pdf link SAMPLE PDF
I might create 4 revision and everything might be all right ... I don't know , sometimes it happens... When I was testing, the problem occours when I create many revisions... THE LAST REVISION THINKS THAT OCSP RESPONSE OF PREVIOUS REVISIONS IS IT'S OWN!
In PADES LTV profile, the final revision must be checked in online
No.
PAdES, i.e. ETSI TS 102 778, in part 4 (PAdES-LTV Profile) merely recommends this:
4.3 Validation Process
It is recommended that that validation process be as follows:
1) The "latest" document Time-stamp should be validated at current time with validation data collected at the current time.
The word should indicates a recommendation, and the sentence before actually spells it out.
But let's assume you want to follow the recommendation. Your interpretation
(It means that OCSP responses, CRLS and certificates of this revision must not be in document secure store (DSS)).
is not correct still: There may be validation related information (OCSP responses, CRLs, certificates) in the document which (seen as isolated information) apply to the outer time stamp or signature. If you time stamp your document twice in short succession using the same time stamp service and add a CRL for certificates used in the first time stamp in the time between, chances are that the outer time stamp involves certificates covered by this CRL and is applied in the validity interval indicated by the CRL.
No, it is the responsibility of the verifier not to use these information if the verifier chose to follow the PAdES-LTV recommendation quoted above.
Adobe Reader does not claim to follow this recommendation (at least as far as I know). Thus, if you verify the signatures and time stamps using Adobe Reader, information contained in the document may be used to verify the outer time stamp, too.
Actually Adobe originally loved the concept of first retrieving validation related information and signing and time stamping everything including those information thereafter.
The problem might be is that following:
Each ocsp response must be unique, even if when we generate them with the same certificate. In the other words, If we request ocsp object twice, they must be unique.
No. While it is good style to use nonces, your observation has nothing to do with them.
The reason why Adobe Reader sometimes (and only sometimes) makes use of already embedded information for verifying outer signatures / time stamps is that OCSP responses and CRLs have validity intervals defined by their thisUpdate and nextUpdate fields which sometimes (if you add multiple time stamps by the same TSA) in spite of being embedded for the validation of an older time stamp still encompass the time of the newly added one (and, thus, are also used for their validation).
If you want to prevent this, you have to check the OCSP responses and CRLs already contained in the PDF or just now added to it by you, inspect those whose respective validity interval has not yet ended, and not apply any time stamp to the document whose certificates can be validated with them.
For some deliveries I require a signature which is an extra charge. I would like to know what that extra charge is, using the rate request API. I'd like to know if this is the place to get that value or if there is some other way.
In the documentation, I only see the SignatureOption element in the explanation for the RateReplyDetails, but nothing for how to send it to them in the RateRequest. The replies always say "SERVICE_DEFAULT" for the SignatureOption with a value of zero. I would like the reply to come back with, for example, INDIRECT and some dollar amount. Other options for this are ADULT, DIRECT, NO_SIGNATURE_REQUIRED, etc.
Below you can see where I tried putting the element under the RequestedShipment element. But that causes the reply to be an "invalid element" error. I tried it in various places in the RateRequest to no avail.
<ns:RateRequest xmlns:ns="http://fedex.com/ws/rate/v7" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ns:WebAuthenticationDetail>
<ns:UserCredential>
<ns:Key>00000</ns:Key>
<ns:Password>00000</ns:Password>
</ns:UserCredential>
</ns:WebAuthenticationDetail>
<ns:ClientDetail>
<ns:AccountNumber>00000</ns:AccountNumber>
<ns:MeterNumber>00000</ns:MeterNumber>
</ns:ClientDetail>
<ns:Version>
<ns:ServiceId>crs</ns:ServiceId>
<ns:Major>7</ns:Major>
<ns:Intermediate>0</ns:Intermediate>
<ns:Minor>0</ns:Minor>
</ns:Version>
<ns:RequestedShipment>
<ns:SignatureOption>INDIRECT</ns:SignatureOption>
<ns:ShipTimestamp>#DateFormat(Now(),'yyyy-mm-dd')#T#TimeFormat(Now(),'hh:mm:ss')#</ns:ShipTimestamp>
<ns:DropoffType>REGULAR_PICKUP</ns:DropoffType>
<ns:PackagingType>YOUR_PACKAGING</ns:PackagingType>
When using more recent versions of the API you need to set the option inside of RequestedPackageLineItems. Only send the element when you've got an actual signature option selection.
<RequestedPackageLineItems>
… dim, weight, etc…
<SpecialServicesRequested>
<SpecialServiceTypes>SIGNATURE_OPTION</SpecialServiceTypes>
<SignatureOptionDetail>
<OptionType>DIRECT|INDIRECT|ADULT|NO_SIGNATURE_REQUIRED</OptionType>
</SignatureOptionDetail>
</SpecialServicesRequested>
</RequestedPackageLineItems>
While adnyknas answer is correct, regarding the place you should put it in your XML, please note that the Signature service request only works in the USA:
This is info I got from FedEX tech support:
Signature Require (SR) services are unavailable in most countries. It is for FedEx Express U.S. package services and FedEx Ground U.S. services only in U.S.A. Refer to below restriction from http://www.fedex.com/us/2014rates/surcharges-and-fees.html