|
Laundry Market
|
Wickets Security
Eight Ways Wickets
Are Protected |
| |
Unique UserID
Each Wicket has a unique 64-bit UserID value
permanently written into its RFID inlay to identify each
manufactured tag. If all of the possible UserID values were used it
mean that everyone on this planet could have about 3 billion numbers
to themselves.... so, we won't be running out anytime soon. The
ISO 15693
specification includes the assignment of a manufacturer ID code
embedded within the UserID so that no two manufacturers will ever
produce an RFID inlay with the same UserID. Thus, it is basically
impossible for your customer to loose money through mistaken
identity of his Wicket with that of another with the same UserID.
|
Unique
SiteID
Each installation receives its own unique SiteID
number which is assigned by the factory. Each of your Wickets will
have this SiteID on it to identify it as belonging to your site.
Each of your Wicket Readers is configured with a
Reader Programming Wicket
using Wickets Administrator
to have a Primary SiteID and two Alternate SiteIDs. The Primary
SiteID is for that particular installation, and the Alternate
SiteIDs are so that if you own more than one installation site, you
can have Customer Wickets from one of your other businesses also
accepted at this site. Authentic Wickets of any other SiteID will be
ignored so that you do not run your equipment for money collected by
someone else... no cross-play with other sites, except for the two
Alternate SiteIDs that you may specify. However, the Equipment Service,
Reader Programming, System Reports, and Banned List Wickets will only be accepted
by a Wicket Reader if they have the Primary SiteID number.
|
Wicket Authentication
To authenticate a responding RFID tag as an IDX
Wicket, a proprietary cipher is used on the UserID, the SiteID, and
FunctionID to generate a
value called the W-Cipher. Only if the calculated W-Cipher matches
that read from the RFID tag will it be accepted as an authentic IDX
Wicket. Otherwise it will be ignored.
|
Password Protection
The RFID chip on a Stored Value Wicket requires that
the reader present a password in order to write to a block of data.
The password is determined by a proprietary encryption cipher which
incorporates the Wicket’s unique UID to ensure that no two Wickets
will have the same password. Once the password is calculated during
the Wicket configuration procedure at the factory, it is stored on
the RFID chip, locked, and made invisible to the outside world. Thus
only the IDX Wicket Reader will be able to store data to a Wicket,
making the Stored Value Wickets immune to so called “clone
attacks” or “replay attacks”.
|
Data Encryption
The Wicket Reader utilizes a proprietary
encryption/decryption cipher when storing and reading values for
each Wicket data block. The cipher incorporates the Wicket’s unique
UID to ensure that even two Wickets storing the same information
will not have the same values written in their blocks. While a
hacker may be able to see the stored data, the hacker will not be
able to interpret it. Furthermore, that data includes an embedded
cipher checksum to verify that data on what may otherwise appear to
be an authentic Wicket is actually valid data... thus preventing a
hacker from creating counterfeit data.
|
Data
Redundancy
The Stored Value Wicket data structure includes
simple redundancy of all important balances and a checksum within
each data block to enable detection of corrupted data. For example,
in the case where the data may possibly be either corrupted or
indeterminate if the Wicket is taken out of read/write range while
the Reader is writing data to the Wicket, the error can be detected
and corrected. In addition to simple error correction, the
strategy prevents a hacker from executing any form of “indeterminate
transaction attack”. Both the customer and the owner are secure from
such an error (purposely or accidentally) resulting in gain or loss
for either.
|
Access Protection
One form of attack on a secured
system is called the “man in the middle” attack where a hacker
utilizes a tool to do his bidding... such as obtaining a Wicket
Reader that knows the encryption algorithm and password algorithm,
and using its command set to write anything to a Wicket that a
hacker may like. To prevent this kind of attack, there are two
levels of access control that are held secret which involve an
unlocking of the write commands and additionally involve an
encrypted “challenge / response” interaction between the
controller and the Wicket Reader in order for the Wicket Reader to
validate the authority of the controller to be sending it a write
command for the Wicket. The protocol is held as a trade secret.
|
Banned List Wickets
One of the features available in the
Turbo Accessories - Registration
package is the ability to create a Banned List of banned UserIDs so that your Wicket Readers will
not accept that specific Wicket anymore.
This includes Customer, Service Equipment, Reader Programming, and
System Report Wickets.
If a registered customer claims he lost a Wicket with $15 on it, you
may choose in good faith to believe him and replace that Wicket with
another pre-valued at $15, but then you should ban his old Wicket UserID
(found in Registration records) by adding it to the Banned List so
that it will be rejected at your Wicket
Readers should someone attempt to later use it. Likewise, if you have fired a service
person or they
claim to have lost their Equipment Service Wicket, you may also want to
ban
that Equipment Service Wicket form further use by adding it to the
Banned List Wicket. Once added to the Banned List Wicket, then just
take the Banned List Wicket around to each of your Wicket Readers
and read it in.
|
|
