Forum Replies Created

  • Re: Re: Forum problems

    9. April 2015 at 16:24
    in reply to: Forum problems
    Hi Aselcuks,

    i apologyze for the delay, unfortunately i did not get email warning about your last post.
    In a few words, PN512 as such has not enough RF output to succeed in coverage of EMVCo full geometric read range. So, based on what you have written, your PN512-implementation has not included a booster amplifier, am i correct?
    About the low level registries and settings, the best would be that you first download complete bundle Package from our EMVCo-level-1 compliant reference design based on PN512, named OM5597/RD2612 12NC: 9352 949 09699 (it indeed contains an RF booster)
    You can download whole bundle SW214513 directly from our web site in this link: http://www.nxp.com/demoboard/OM5597.html#showall
    You'll see two items marked with "safe vault": if you click the button, you can print a "mini-NDA" one page to print, write your company name, phone, email, sign it and send back via fax to NXP. We will send you a username and password that will be used to give you access to this Package bundle. On the other hand, get in touch with NXP GSM FAE that covers your region/country if you want to order one working sample of this POS reference design.
    If you are interested in more EMVCo insights (RF design, EMVCo FW, etc) i can address you to an EMVCo NXP webinar.
    If you have more questions, don't hesitate to write again.
    Cheers
    Rodolfo
    + 0  |  - 0

    Re: Re: Forum problems

    2. April 2015 at 15:03
    in reply to: Forum problems
    Hi Chiase, hi Aselcuks, what exactly questions you placed that were not answered?
    Perhaps copy and paste them here.
    Cheers
    Rodolfo
    + 0  |  - 0

    Re: Re: MIFARE DESfire V1

    2. April 2015 at 14:58
    in reply to: MIFARE DESfire V1
    Hi Funex,
    actually MIFARE DESFire EV1 (not "V1") has only hard-coded symmetric criptography (not asymmetric). It means, its built-in card operating system supports so-called 3-step authentication both using 3DES keys (168bit-key-lenght), as well as AES (128bit-keylenght).
    This should be explained in MIFARE DESFire EV1 short form datasheet. Nevertheless, this technology looks like a small empty hard-disk, so you can write a bunch of signed-cryptograms, store them with access condition of READ-only files, so that people who tap with an Android phone will for sure read such cryptograms, but you have to implement asymmetric crypto calculations by your own on the Android app.
    If you download MIFARE SDK -advanced version, you can handle DESFire commands (symmetric crypto) but bear in mind it is necessary to implement digital-signature verification or other PKI (public key infrastructure) techniques by your own. Try to download and install MIFARE SDK-lite version (freeware) and get familiarity with it. Then you can download more info about MIFARE SDK-advanced version (not for free) and compare both. In order to handle digital signature verification, there is a lot in the internet and in NXP application notes. Just give a search using NXP search engine on top right of your screen www.nxp.com
    Cheers
    Rodolfo
    + 0  |  - 0

    Re: Re: Change Uid with CLRC663

    20. March 2014 at 17:11
    in reply to: Change Uid with CLRC663
    Hi Yesilkaya,
    No, NXP does not guarantee CLRC663 will work fine if you try to send non-standard proprietary commands different from those listed below:
    Read/write mode supporting ISO/IEC 14443A/MIFARE
    • Read/write mode supporting ISO/IEC 14443B
    • Read/write mode supporting JIS X 6319-4 (comparable with FeliCa1 (see
    Section 21.5) scheme)
    • Passive initiator mode according to ISO/IEC 18092
    • Read/write mode supporting ISO/IEC 15693
    • Read/write mode supporting ICODE EPC UID/ EPC OTP
    • Read/write mode supporting ISO/IEC 18000-3 mode 3/ EPC Class-1 HF

    Nevertheless, if you have a proprietary ISO14443-4 card for which you have a native set of APDU's, you have more freedom when using CLRC663 in T=CL protocol since reader will push through APDU in the payload (reader doesn't care what you are sending to your card). Then, it will be up to your card to reply with "ok" or with "error message". When using MIFARE Classic related commands (on ISO/IEC14443-3), then you have to stick to only available MIFARE available commands in the list.
    I hope this helps you.
    Cheers
    Rodolfo
    + 0  |  - 0

    Re: Re: Is DESFire EV1 UID unique and always returned?

    9. August 2013 at 10:46
    in reply to: Is DESFire EV1 UID unique and always returned?
    Hi,
    it is possible to configure DESFire EV1 card to exhibit a Random ID; such configuration can be done during card personalization.
    You can find more information in this application note: page 5, page 7 and page 8.
    http://www.nxp.com/documents/application_note/AN10927.pdf

    Cheers
    Rodolfo
    PS: Ioulupukki is SantaClaus in Finish, isn't it ??
    + 0  |  - 0
Viewing 5 posts - 1 through 5 (of 5 total)