I am trying to digitally sign files using the signing certificate located on my national ID smart card with NFC. I can digitally sign it over smart card reader, but I am trying to achieve the same thing over NFC.
I'm pretty sure it is implementing the ISO-7816 standards and ICAO-9303 (not sure if thats means something), but I am not able to find hardware specifications for concrete APDU-s to digitally sign a file (if it is even possible)
I am able to do PACE authentication and read all the ID data stored inside using this project.
What I tried to do as a first step is get number of PIN tries left using the following APDU:
0x00, 0x20, 0x00, 0x80, 0x00
But I get sw1 - 0x6A, sw2 - 0x82 which corresponsds to message "File not found".
I am not sure in which direction I should continue.
Also, I should probably mention it is a national ID of an EU country.
I am trying to digitally sign files using the signing certificate located on my national ID smart card
Machine readable travel document (MRTD) from Doc 9303 doesn't sign files. First of all, it's just a travel document. EU citizen card is different document for different purposes. You better need European Citizen Card specification prCEN 15480 and BSI TR-03110.
There you can find eIDAS Token specification that can deal with eServices, certificates, signatures and so on.
Related
Anyone knows what are these 2 here:
https://learn.microsoft.com/nl-nl/office/vba/outlook/concepts/forms/item-types-and-message-classes
IPM.Note.Secure :: Encrypted notes to other people
IPM.Note.Secure.Sign :: Digitally signed notes to other people
I mean secure email messages have these 2 IPMs:
IPM.Note.SMIME, IPM.Note.SMIME.MultipartSigned
I don't think that sticky notes can be signed or encrypted? (or I'm wrong?) So what are Note.Secure and Note.Secure.Sign?
Thanks
These are standard message classes in Outlook that belong to mail items, not sticky notes as you could think.
IPM.Note - Normal e-mail message.
IPM.Note.SMIME - The message is encrypted and can also be signed.
IPM.Note.SMIME.MultipartSigned - The message is clear signed.
IPM.Note.Receipt.SMIME - The message is a secure read receipt.
But the following message classes belongs to notes:
IPM.Note.Secure - Encrypted notes to other people
IPM.Note.Secure.Sign - Digitally signed notes to other people.
From the MAPI point of view every items is considered to be sent. Outlook applies its own business rules the low-level code. See Item Types and Message Classes for more information.
Also you may find the 2.2.2.49 MessageClass section for more information about possible variations and their meanings.
I have created service to offer the brands to create appointment passes and send via email, brands can create passes and send notification using my service.
This service allows them to send push notifications and using their brand name Can someone suggest as per attached image it’s in conflict or not
.
This clause authorizes your customers to send you their certificates for your service to manage on their behalf. This is a good thing and what you want them to do.
If I read between the lines, I believe you are asking if your service can your own single certificate to send to multiple brands. Attachment 5 to the Developer Agreement states:
You may use the Pass Type ID only for purposes of digitally signing
Your Pass for use with Wallet and/or for purposes of using the APN
service with Your Pass. You may distribute Your Pass Type ID as
incorporated into Your Pass in accordance with Section 2 below only so
long as such distribution is under Your own trademark or brand. To the
extent that You reference a third party’s trademark or brand within
Your Pass (e.g., a store coupon for a particular good), You represent
and warrant that You have any necessary rights. You agree not to
share, provide or transfer Your Pass Type ID to any third party
(except for a Service Provider and only to the limited extent
permitted herein), nor use Your Pass Type ID to sign a third party's
pass.
This strongly suggests you should only use your certificate for passes bearing your own trademark or brand.
It's a grey area. Only you can really decide whether or not you want to risk having your certificate revoked.
In the EMV protocol the IMK(ac) is used to generate the session key, which is used to generate an ARQC. The IMK(ac) is exclusive to the chip and the card issuer host
As far as I understand, the card issuers do not share those keys with the card brand (i.e. Visa cannot validate your ARQC, only "The Bank of Peoria" who issued the card can).
When an EMV Apple Pay transaction occurs in which the phone generates the ARQC, which IMK(ac) key is it using? Presumably it can't be the IMK(ac) from the original card, and thus the card issuer cannot validate the ARQC.
If it's an Apple IMK(ac) being used, then does this mean that it is Apple validating that ARQC?
If this is the case, what's the transaction flow that gives Apple the opportunity to validate the ARQC?
[Edited for clarity]
Mobile wallets like Apple/Google Pay don't use the card's PAN, so they don't need to provide the same ARQC that the card would have generated.
Instead, they use network tokens which are then mapped back to the PAN by the scheme.
Before the transaction
the Token Requestor (e.g. Apple) sends its IMKac to the Token Service Provider (e.g. Visa) as part of the onboarding
the Device (i.e. individual phone) is provisioned with a Token that can be mapped back to the PAN by the Token Service Provider as part of adding the card to Apple Pay
During the transaction
the Device:
generates an ARQC, which it includes in the transaction
sends its Token in the place that the PAN would go
the Token Requestor:
swaps out the Token for the PAN, which the issuer can recognise
validates the ARQC using the Token Requestor's IMKac, and forwards the result of this validation to the issuer
Encryption will always use Session keys derived from an IMKac for Cryptogram generation. However the IMK need not be the same as what your physical card uses( you can manage this using a different CVN as host).
The same key will be available with the payment schemes(Visa, MasterCard etc.) who will validate the cryptogram during the transaction and send you the results of verification.
Wallet CVNs are different. If you as a card issuer host wants to verify the cryptogram, then you should have the IMKac for the CVN and your HSM should support the CVN. Ideally you can rely on the verification results code (in 44 for Visa and 48 SE71 for MC) to decide whether it can be approved or no.
In case if you have more documentations from Apple you can share, I would love to go through those :-) .
I am working with a company that has already defined a URI in the filter handling/android manifest ex "brand://start" - the challenge is that they didn't anticipate the need to call a URL if the handset doesn't have their app installed. I am wondering what I would encode on an NFC tag to handle their URI and a backup URL if their app is not found.
I would prefer to write a second NDEF record (url brand.domain.com/download)..
so, all that said (assuming i have no access to their manifest file) how can i encode a tag to handle both options?
In case of an Android device, you can simply add an Android Application Record to the NDEF message. This will ensure that when the app is not installed the user is redirected to the Play Store to install it.
I've seen other companies do this, but Google is a notable example.
When you turn on two-factor authentication with Google, one of the options is to receive an SMS when you logon. I've noticed that the sender's address, rather than being an MSISDN like 346-555-1234 is "Google".
How are they doing that?
In the smpp 3.4 specifications, the source address can be defined as an alphanumeric string of 11 characters