Please see the transaction post
VPSProtocol=4.00&TxType=PAYMENT&Vendor=Vendorname
&VendorTxCode=324234906133500
&Amount=20.00
&Currency=GBP
&Description=Payment
&BillingSurname=Jo
&BillingFirstnames=Test
&BillingAddress1=43
&BillingCity=Ash
&BillingPostCode=Asd234
&BillingCountry=GB
&BillingPhone=323-8412233
&CustomerEMail=test#test.com
&DeliverySurname=Jo
&DeliveryFirstnames=Test
&DeliveryAddress1=43
&DeliveryCity=Ash
&DeliveryPostCode=Asd234
&DeliveryCountry=GB
&DeliveryPhone=323-8412233
&AllowGiftAid=0
&ApplyAVSCV2=1
&Apply3DSecure=1
&Profile=LOW
&VendorData=Rent
&NotificationURL=https://testpage/notificationpage.aspx
Please see the Transaction Post Response below
Status: OK
VendorTxCode: 324234906133500
VPSTxId: {8652345E-5B25-49F1-DD23-1B9CCC2B6545}
Security Key: AZFE2KOSDS
VPSSignature: N135C007EF1643ABE44CAC12EBD9ED43
StatusDetail: 0000 : The Authorisation was Successful.
TxAuthNo: 34234532
AVSCV2: SECURITY CODE MATCH ONLY
AddressResult: NOTMATCHED
PostCodeResult: NOTMATCHED
CV2Result: MATCHED
GiftAid: 0
3DSecureStatus: OK
CAVV: Y2c2ZVVBeTRvTUVwVGtpaGVMdzk=
AddressStatus:
PayerStatus:
CardType: VISA
Last4Digits: 0006
DeclineCode: 00
ExpiryDate: 0123
BankAuthCode: 999777
Surcharge: 0.40
FraudResponse:
ACSTransID: 490ead88-8dc8-4ac4-b40a-fbe1f8a95182
DSTransID: 3f06865c-33c1-462c-956d-01f4c55114b5
SchemeTraceID: Wkv0Jq8QEYu4DupyW0gG}s2~}N2K~U+7LAMYCVU0vXt2uH0prPJCpY6
The Issue is VPSSignature is not matching after computing the MD5 signature
VPSTxId+VendorTxCode+Status+TxAuthNo+VendorName+AVSCV2+SecurityKey+AddressResult+ PostCodeResult+CV2Result+GiftAid+3DSecureStatus+CAVV+AddressStatus+PayerStatus+CardType+ Last4Digits+DeclineCode+ExpiryDate+FraudResponse+BankAuthCode+ACSTransID+DSTransID+SchemeTraceID
SERVER Integration POST URL: https://test.sagepay.com/gateway/service/vspserver-register.vsp
Have you validated your code that builds the signature to be compared against VPSSignature in the Post response? Are they salting the MD5? Are you feeding it the exact payload? I fed your Post into an MD5 generator and I got 79dda36adfdc796412ab0fa77ca67380 instead of N135C007EF1643ABE44CAC12EBD9ED43 .
Related
I received an email (using Office365) which had the following:
spf=pass
dkim=fail (body hash did not verify)
dmarc=pass action=none
compauth=pass reason=100
Should DMARC not fail when DKIM fails or?
Part of mail header (redacted):
Authentication-Results: spf=pass (sender IP is 185.XXX.XXX.XXX)
smtp.mailfrom=xxxxx.com; yyyyy.com; dkim=fail (body hash did not verify)
header.d=xxxxx.com;yyyyy.com; dmarc=pass action=none
header.from=xxxxx.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of xxxxx.com designates
185.XXX.XXX.XXX as permitted sender) receiver=protection.outlook.com;
client-ip=185.XXX.XXX.XXX; helo=xxxxx.com;
Received: xxxxx.com (185.XXX.XXX.XXX) by
XXXXT057.mail.protection.outlook.com (10.152.5.104) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.3370.16 via Frontend Transport; Tue, 15 Sep 2020 09:28:04 +0000
Received: from [10.244.53.49] (unknown [62.xxx.xxx.xxx])
(Authenticated sender: johndoe#xxxxx.com)
by xxxxx.com (Postfix) with ESMTPSA id 958xxxxxx
for <janedoe#yyyyy.com>; Tue, 15 Sep 2020 09:27:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 xxxxx.com 95811831E7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xxxxx.com;
s=default; t=1600162079;
bh=nuM3cWrinDLZjraJCy30WYG0ePetEpsDwkYbe7tHCOs=;
h=Date:Subject:From:To:From;
b=jJZ91ejcq4Tu3xV+PtcT1/pgwHbUXQRxFLbilFKFiYTnBi1Zn31vzAHbPe4o40HM0
gi+7F9TdBu47MhNwTFIvY94M+uSx1U4B9Ci9hTSDwEaDGazONyB8ER1fFmD7LPRMvV
oXdTEACywQrrYPPb15RkSUNg6m8+6AJjdMgDrRDU=
Short answer:
No, DMARC fails if and only if:
SPF or SPF Alignment has failed, and
DKIM or DKIM Alignment has failed
If only one of them fails and the other passes, DMARC will pass.
Some more details around DMARC failures and the protocol in general:
An important detail to keep in mind from the perspective of DMARC is that a failure for SPF or DKIM can mean 2 things:
The underlying SPF or DKIM authentication has failed, or
The underlying SPF or DKIM alignment has failed.
Authentication is probably clear since it is related to the underlying protocols themselves.
Alignment is an additional feature introduced by DMARC, which checks if the domains used for the SPF/DKIM authentication are in alignment with the domain portion of the RFC5322.From domain (which is the domain portion of the sender's email address, e.g. senderxyz#domain.com).
A successful SPF/DKIM alignment implies that the domains are either identical or that the SPF/DKIM domain is a subdomain of the RFC5321.From domain. This is called a strict or relaxed alignment respectively, and can be controlled via the aspf and adkim tags in your DMARC Record.
I read here that EVM cards will sign some transaction data.
I would like to do this with my card, using my phone, and verify that the signature on the result is correct.
To start, I issued this command ("request APDU"):
00:A4:04:00:0E:32:50:41:59:2E:53:59:53:2E:44:44:46:30:31:00
One of the "Application IDs" was this:
A00000038410
So then I issued this command ("Select Payment application"):
00:A4:04:00:07:A0:00:00:00:03:10:10:00
and it returned this "Processing Options Data Object List (PDOL)":
9F66049F02069F37045F2A02
I read here how to decode this, because I couldn't find the official spec anywhere:
9F6604 - the tag 9f 66 represents the terminal transaction qualifiers
9F0206 - tag 9f 02 stands for authorized amount. The PDOL list must have the amount, authorized, coded into 6h bytes added to it.
9F3704 - tag 9f 37 stands for unpredictable number, thus encode such a number in 4 bytes and add it to the list
and here how to decode this:
5F2A02 - TX currency code
I understand the next step is to run "Get Processing Options" but this is where I got stuck. I tried:
80:A8:00:00:02:83:00:00
80:A8:00:00:12:83:10:01:02:03:04:05:06:07:08:01:02:03:04:05:06:07:08:00
80:A8:00:00:12:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
80:A8:00:00:02:83:10:F3:20:40:00:00:00:00:01:00:00:04:04:06:03:05:08:00
All gave back a result of 6D:00 (Instruction code not programmed or invalid).
I tried looking in "emv book 3" and "emv book 4" but neither seem to contain the relevant information.
What do I need to do next in order to make a transaction, sign, and check the result?
Your GPO commands needs to provide the PDOL values requested by the card. The requested tags are:
9F66 - 4 bytes
9F02 - 6 bytes
9F37 - 4 bytes
5F2A - 2 bytes
So the commands needs to provide these in the same order, with expected lengths.
Assuming you want to send the following sample values:
9F66: 11223344
9F02: 112233445566
9F37: 11223344
5F2A: 1122
Your GPO command will look like this:
80A800001283101122334411223344556611223344112200
Where the PDOL data is 11223344112233445566112233441122.
Hope this helps
If PDOL found in response of select application, here you need to pass the value of PDOL tags in GPO command,
can find a very good article Here. hope it helps.
I have empty JavaCOS A40 smartcard and want make it a PKCS PKI card.
I'm going to use it as ssh key and for e-contracts signing. Russia don't provide smartcard-based e-id for citizens like EU countries do. Commercial e-signature providers are selling some sort of password-protected usb drives, that's unsafe to use, because you can easily export private key. Also they sell normal smartcards, but they are really expensive(x10-x20 than empty javacard) and short-living(about 1 year). So i want to make my own PKI card based on RSA algorhitms from javacard.
Now my javacard is in state OP_READY and I don't changed it, because changes are irreversible. It use default key and anyone can upload anything. I use ACR38U reader with pcsc linux driver on Ubuntu and it works as expected, so I used GlobalPlatformPro to upload PKI IsoApplet as default. So GP's output:
java -jar gp.jar -list
Warning: no keys given, using default test key 404142434445464748494A4B4C4D4E4F
ISD: A000000003000000 (OP_READY)
Privs: SecurityDomain, CardLock, CardTerminate, CardReset, CVMManagement
APP: F276A288BCFBA69D34F31001 (SELECTABLE)
Privs: CardReset
PKG: F276A288BCFBA69D34F310 (LOADED)
Version: 1.0
Applet: F276A288BCFBA69D34F31001
cardpeek successfully connects to it and I can send low-level commands to applet
But when I try to connect to card and applet using opensc prober to see Answer-To-Request(ATR), it fails opensc-tool --reader 0 --atr. See maximum debug info
Shortened version:
opensc-tool --reader 0 --atr -vv
Connecting to card in reader ACS ACR 38U-CCID 00 00...
0x7fc849e7e740 22:17:14.634 [opensc-tool] card.c:200:sc_connect_card: called
0x7fc849e7e740 22:17:14.634 [opensc-tool] card-entersafe.c:138:entersafe_match_card: called
Failed to connect to card: Card command failed
0x7fc849e7e740 22:17:14.797 [opensc-tool] ctx.c:870:sc_release_context: called
According to manufacturer info, card is supporting T=0 over ISO7816, but opensc tries to communicate with T=1. So how I can fix this?
Seems, that opensc tools are not customizable. I need to use pkcs15-crypt, but it can't connect. May I change drivers, recompile opensc with patches, or use another utility? How another ways I can use to work with OpenPGP for example?
Your problem is certainly not with the transport protocol because it communicates an APDU with the card. When looking at the logging it seems to incorrectly guess from the ATR that the card is an epass2003:
0x7f175a21e740 22:14:13.904 [opensc-tool] card.c:287:sc_connect_card: matched: epass2003
then execute a command to it:
0x7f175a21e740 22:14:13.904 [opensc-tool] apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:86, data(0) (nil)
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:283:pcsc_transmit: reader 'ACS ACR 38U-CCID 00 00'
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:284:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 86 00 .....
0x7f175a21e740 22:14:13.904 [opensc-tool] reader-pcsc.c:212:pcsc_internal_transmit: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:293:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:390:sc_single_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] apdu.c:543:sc_transmit: returning with: 0 (Success)
0x7f175a21e740 22:14:13.912 [opensc-tool] card.c:459:sc_unlock: called
0x7f175a21e740 22:14:13.912 [opensc-tool] reader-pcsc.c:662:pcsc_unlock: called
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:189:epass2003_check_sw: Instruction code not supported or invalid
0x7f175a21e740 22:14:13.921 [opensc-tool] card-epass2003.c:1118:get_data: get_data failed: -1204 (Unsupported INS byte in APDU)
Now this command is executed over the communication channel in T=1 (it's very unlikely that the card just supports T=0 if it also supports T=CL, because T=CL and T=1 are very much alike - at the higher level). Not only that, it correctly returns a result, even if that is higher level error condition: 6D00 meaning instruction not supported.
This leads to the high lever error condition:
Failed to connect to card: Card command failed
which is slightly misleading, because it certainly connected to the card, it just wasn't able to get any data from it using a GET DATA command. This isn't that strange because it didn't first select any applet and GET DATA (with INS-truction CA) is not likely to be present in the root folder / applet.
TL;DR your connection is fine, now start programming it by issuing GlobalPlatform card manager commands to it. If possible use a different tool or get opensc tools to skip the identification phase / initial commands to it.
IsoApplet and OpenPGP are two different world. For OpenPGP support, look at either SmartPGP by ANSSI-FR on github or ykneo-openpgp (also on Github).
For signatures, you also do not need pkcs15-crypt but should work via PKCS#11 library instead.
For this specific reason - the card being matched as epass, disable the epass driver in opensc.conf.
I'm writing an web server with Lisp to handler HTTPS request. I followed TLS 1.2 and already completed the handshake process. The Cipher Suite I chose is TLS_RSA_WITH_RC4_128_SHA. I already calculated client_write_MAC_secret, server_write_MAC_secret, client_write_key, server_write_key. These keys seems are correct, because I can decrypt "Finished" message from browser and validate the data inside. I also validate the HMAC of the record layer. Then I send a "Change Cipher Spec" and "Finished" from server. So far everything seems working fine.
Then I got the message from browser start with #(23 3 3 1 61 ...). 23 means it's an application data. #(3 3) means TLS 1.2. #(1 61) means length is 256+61=317 which is correct because the data left is really 317 bytes long. Here comes my question: I decrypted these 317 bytes with RC4 using the "client_write_key" then I got data like #(148 104 81 182 67 111 28 201 202 50 207 57 126 209 19 ...) which can't be converted to text. I thought I should get something like GET / HTTP/1.1. What do I get wrong?
Thanks.
RC4 is a stream cipher and, according to RFC 5246, section 6.2.3.1, "For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet."
So, the first record you decrypt is the FINISHED message and the first application data you decrypt should be with the RC4 state as it was left after decrypting the FINISHED message.
Is there a way to retrieve the ZAP channel from an extension number through the Manager API?
For example, this is what I see when I run "zap show channels":
Chan Extension Context Language MOH Interpret
...
33 3594 from-zaptel en default
...
But Manager API only returns the following (without extension):
Event: ZapShowChannels
Channel: 33
Signalling: FXS Kewlstart
Context: from-zaptel
DND: Disabled
Alarm: No Alarm
ActionID: aci-1234
You did not mention which version of asterisk you are working with. I assume asterisk 1.2 because in newer versions "zaptel" has been renamed to "dahdi".
It's a bit of a work around, but you can request the missing information for each channel with the "GetVar" Action.
send:
Action: GetVar
Channel: Zap/33
Variable: EXTEN
receive:
Response: Success
EXTEN: 3594