I'm developing a system including NFC tags and Android phone , using unique ID of NFC tags .
But don't know what is the differences between 4 types NFC tag .
I've found this :
"NFC-compatible tags can be of the following technologies/standards
and each of them has a different notion of ID:
NFC Tag1 : Topaz/Jewel
NFC Tag2 : Mifare UL (ISO14443A-3)
NFC Tag3 : JIS X 6319-4 (FeliCa)
NFC Tag4 : ISO14443-4A or ISO14443-4B tag
There is also an unofficial support of the Mifare Classic cards as NFC tags.
And each of them define some identification number.
Topaz/jewel has a 4-byte ID
Mifare UL has a 7-byte UID
Mifare Classic has a 4 or 7-byte UID
FeliCa has a 8-byte ID
ISO14443-4A has a 4, 7 or 11-byte UID
ISO14443-4B has a 4-byte PUPI
Do some tests with nfc-list, you'll see what comes out depending on the used tag.
And for code, see code of nfc-list.c how IDs are retrieved and displayed."
Is that true and is thera anything else ?
Can you help me ?
Read more about nfc tags with these links.
http://www.nfc.cc/technology/nfc-tag-types/
http://www.radio-electronics.com/info/wireless/nfc/near-field-communications-tags-types.php
Type 1: Tag is based on ISO/IEC 14443A. This tag type is read
and re-write capable. The memory of the tags can be write protected.
Memory size can be between 96 bytes and 2 Kbytes. Communication Speed
with the tag is 106 kbit/sec. Example: Innovision Topaz
Type 2: Tag is based on ISO/IEC 14443A. This tag type is read and
re-write capable. The memory of the tags can be write protected.
Memory size can be between 48 bytes and 2 Kbytes. Communication Speed
with the tag is 106 kbit/sec. Example: NXP Mifare Ultralight, NXP
Mifare Ultralight
Type 3: Tag is based on the Japanese Industrial Standard (JIS) X
6319-4. This tag type is pre-configured at manufacture to be either
read and re-writable, or read-only. Memory size can be up to 1 Mbyte.
Communication Speed with the tag is 212 kbit/sec. Example: Sony Felica
Type 4: is fully compatible with the ISO/IEC 14443 (A \& B) standard
series. This tag type is pre-configured at manufacture to be either
read and re-writable, or read-only. Memory size can be up to 32
KBytes; For the communication with tags APDUs according to ISO 7816-4
can be used. Communication speed with the tag is 106 kbit/sec.
Example: NXP DESfire, NXP SmartMX with JCOP.)
Further more information about UID tag size and other specification details are contain with this link.
https://www.tagnfc.com/en/info/11-nfc-tags-specs
Just some bits for your consideration:
Topaz / Juwel tags from Broadcom (previously Innovision) are getting very to hard to find. It seems Broadcom is no longer supporting them.
The Mifare Classic are not included in the NFC standard. Devices with the protocol stack from NXP (all up to Android 4.1x) do support them anyway, so they are popular, because of their large memory. But since Android 4.2 (e.g. Nexus 4 or Nexus 10) the NFC stack is from Broadcom and the Mifare classic ist not supported anymore.
Felica tags are often hard to find.
So the safe route are tags with Mifare UL or NXP Ntag chips.
Related
I have some trouble understanding the value of Time (0040,A122) tag. I am trying to update an anonymization software, but I can't seem to find any example of the actual tag.
The DICOM standard (PS 3.3) mentions that:
This is the Value component of a Name/Value pair when the Concept implied by Concept Name Code Sequence (0040,A043) is a time.
Note
The purpose or role of the date value could be specified in Concept Name Code Sequence (0040,A043).
Required if the value that Concept Name Code Sequence (0040,A043) requires (implies) is a time. Shall not be present otherwise.
So basically Concept Name Code Sequence (0040,A043) specifies what type of time it is? I would like to know what are some examples of Concept Name Code Sequence?
I would suggest to have a look at the SR sample given from the DICOM standard section PS 3.20:
A.7.2 Target DICOM SR "Measurement Report" (TID 1500)
In particular:
>>>>1.5.1.1.4: HAS ACQ CONTEXT: TIME: (111061,DCM,"Study Time") = "070844"
You may also want to check PS 3.16 for the definition of TID 1500:
TID 1500 Measurement Report
Just as a reminder, Enhanced SR are defined in PS 3.3:
A.35.2 Enhanced SR IOD
How to identify different types of MIFARE Ultralight tags?
In document AN10834 Ultralight and Ultralight C differ by the answer from "Auth". What is this "Auth"? There is no description of this function in the datasheets to the chips.
I noticed that Ultralight C and EV1 support GET_VERSION (60h), I sent this request to EV1 card, it does not return anything to me.
In order to distinguish MIFARE Ultralight, Ultralight C, Ultralight EV1, and NTAG tags, you would first send a GET_VERSION command:
> 60
If this command succeeds, you know that the tag is an EV1 (or later) tag (e.g. MIFARE Ultralight EV1 or NTAG21x). You can, thus, narrow down the specific tag type by analyzing the resonse to the GET_VERSION command. This will reveal the product type (NTAG or Ultralight EV1) as well as product subtype, product version and storage size (which allows you to determine the exact chip type). See Distinguish NTAG213 from MF0ICU2 for a list of example product identification values.
If the GET_VERSION command fails, you can assume that it is a first generation tag (MIFARE Ultralight, Ultralight C, NTAG203). You can, thus, narrow down the specific tag type by sending an AUTHENTICATE (part 1) command:
> 1A 00
If this command succeeds, you know that the tag is MIFARE Ultralight C.
If this command fails, you can assume that the tag is either Ultralight or NTAG203. In order to distinguish between MIFARE Ultralight and NTAG203, you can try to read pages that do not exist on Ultralight (e.g. read page 41):
> 30 29
i'm trying to use iab.taxonome.org service to classify texts, and get error response -5 (text too short)
Here is what i'm sending to the service:
https://rest.taxonome.org/v1/taxono?me=A college basketball game at Allen Fieldhouse, in Lawrence, Kansas, the home of the Kansas Jayhawks
The history of basketball is traced back to a YMCA International Training School, known today as Springfield College, located in Springfield, Massachusetts&token=[...MyKey...]&ver=1
Indeed I had the same issue. After clearing this with taxonome support team I figure out there is a requirement for at least 500 words per classification.
I have asked to add it to the API reference page.
Double checking and editing my answer: It is depends which framework is being used to send this data. In case you are implementing the client and not encoding the URL string it won't work for you (e.g. space = %20).
Check the API example here:
https://iab.taxonome.org/api
Could you please explain me more in details eventually giving me some example (one for attached and one for detached) of what iText detached signature exactly means?
I found this wonderful documentation: iText digital signature pdf about iText digital signature but I'm still not sure I understand the iText detached signature concept.
Reading the documentation (see the link) I found this definition:
In PDF, we sometimes refer to a detached signature. According to Wikipedia, a detached signature is a type of digital signature that is kept ‘separate from its signed data’, as opposed to ‘bundled together into a single file’. This definition isn’t entirely correct in the context of PDF: the signature is enclosed in the PDF file, but the attributes of the signature are ‘part of the signature’, as opposed to ‘stored in the signature dictionary’.
where is not clear for me what "attributes of the signature" means (what signature attributes it's refer?)
Note that the author of the article (iText documentation) is working with this snippets of a signed PDF file:
%PDF-1.4
%âãÏÓ
3 0 obj
<</F 132/Type/Annot/Subtype/Widget/Rect[0 0 0 0]/FT/Sig
/DR<<>>/T(signature)/V 1 0 R/P 4 0 R/AP<</N 2 0 R>>>>
endobj
1 0 obj
<</Contents <0481801e6d931d561563fb254e27c846e08325570847ed63d6f9e35 ... b2c8788a5>
/Type/Sig/SubFilter/adbe.pkcs7.detached/Location(Ghent)/M(D:20120928104114+02'00')
/ByteRange [0 160 16546 1745 ]/Filter/Adobe.PPKLite/Reason(Test)/ContactInfo()>>
endobj
...
9 0 obj
<</Length 63>>stream
q
BT
36 806 Td
0 -18 Td
/F1 12 Tf
(Hello World!)Tj
0 0 Td
ET
Q
endstream
endobj
...
11 0 obj
<</Type/Catalog/AcroForm<</Fields[3 0 R]/DR<</Font<</Helv 5 0 R
/ZaDb 6 0 R>>>>/DA(/Helv 0 Tf 0 g )/SigFlags 3>>/Pages 10 0 R>>
endobj
xref
0 12
0000000000 65535 f
...
0000017736 00000 n
trailer
<</Root 11 0 R/ID [<08ed1afb8ac41e841738c8b24d592465><bd91a30f9c94b8facf5673e7d7c998dc>]/Info 7 0 R/Size 12>>
startxref
17879
%%EOF
While the white paper you quoted from, Digital Signatures for PDF documents by Bruno Lowagie, indeed is a must-read for anyone attempting to create integrated PDF signatures using iText (and a good source of information even if you are not using iText), I concur that the explanation therein of the use of the word "detached" in "detached PDF signature" doesn't really hit home:
NOTE: In PDF, we sometimes refer to a detached signature. According to Wikipedia, a
detached signature is a type of digital signature that is kept ‘separate from its signed data’, as
opposed to ‘bundled together into a single file’. This definition isn’t entirely correct in the
context of PDF: the signature is enclosed in the PDF file, but the attributes of the signature
are ‘part of the signature’, as opposed to ‘stored in the signature dictionary’.
First of all, calling these signatures "detached" is not a term enforced by any current specification. The reason why we do so anyway, is that the identifier used in the signature dictionaries of such signatures (adbe.pkcs7.detached or ETSI.CAdES.detached) contains that word.
Thus, the question actually should be: Why do these identifiers contain the word "detached"?
To understand this one needs to know that originally there were two kinds of integrated PDF signatures which embed a PKCS#7 signature container into the PDF, respectively identified by adbe.pkcs7.detached and adbe.pkcs7.sha1.
The difference between these two types of signatures is that
for adbe.pkcs7.sha1 signatures a SHA1 digest for the signed byte ranges of the PDF is calculated and embedded in the ContentInfo structure of the signature container and this embedded data packet is signed in the PKCS#7 way;
for adbe.pkcs7.detached signatures, on the other hand, the ContentInfo structure of the signature container is left empty and the signed data ranges of the external document are signed in the PKCS#7 way.
Thus, in case of adbe.pkcs7.sha1 signatures the actually signed data are embedded in the container while in case of adbe.pkcs7.detached signatures the actually signed data are not.
Thus, on the level of the PKCS#7 signature containers signed data and signature are detached from each other in the latter case.
(The fact that signing in the PKCS#7 way can --- and usually does --- include calculating a hash of the data to sign, adding this hash to a number of so-called authenticated attributes, and eventually signing these special attributes, shouldn't distract us.)
The other type of detached signatures (ETSI.CAdES.detached) are constructed similarly to the adbe.pkcs7.detached containers. The differences between them mostly are the profiling of additional attributes of the container.
The white paper's argumentation concerning attributes being part of the signature container actually illustrate the difference between all the signature types mentioned before and adbe.x509.rsa_sha1 signatures which is the third original integrated PDF signature type. This type is not based on signature containers but fairly naked signatures; thus, any extra information in that case has to be stored in their own structures in the PDF
I hava a problem with barcode in ireport. I use ireport 3.7.4 with berbecue and barcode4j library.
I want to put into the EAN128 barcode following data:
253 application Identifier (Global Document Type Identifier) value 24.1 (document type) + 2076764 (document id)
414 application Identifier (Global Location Number) value 2095
91 application Identifier (Company internal information) value 20110101.
I used component barcode4j and barbecue, unfortunately without effect.
Both like barbecue and Barcode4j component doesn't recognize 253 and 414 application identifiers.
Could anybody explain me why I'm wrong and write a correct code expression.
From Barcode4J EAN-128 document:
The allowed data types are "n" (numeric), "an" (alpha-numeric), "d"
(date) and "cd" (check digit).
I'm not sure whether you can put a dot in the data.
To locate the source of the error, try adding one part of the barcode data at a time.