RFID Guardian ACL Testing

From RFID Guardian

Contents 1 RFID Guardian ACL Testing 2 anti collision 3 basic context 4 case sensitive 5 Circular tag sets and circular reader roles 6 Deny has a higher priority 7 different request 8 does star work 9 empty rules, tag sets and roles 10 explicit inventory 11 explicit multi 12 nested rule, role and tagsets 13 priority 14 X include Y 15 reader or tag on the same line 16 same X declared twice 17 simplest accept 18 simplest deny 19 superset role or tagsets

RFID Guardian ACL Testing

RFID Guardian should understand Access Control List correctly. Following are the current tests used to ensure software quality. The full test script and test could be download here

ACL testing efficiency issue goes Here

anti collision

RFID Guardian implements anti-collision algorithm, because occasionally it has to act as an RFID reader. This test contains a bash script implementing the same algorithm. The test uses this bash script to generate query files and expected result files. Then the master script runs MRG with the same query files for simulation and tests if the decisions from MRG and the bash script match.

basic context

how the software behaves,

1, if the user does not provide any context.

2, if the user does provide a legal context.

3, if the user provides a wrong context.

case sensitive

The current design of MRG is that it is case sensitive, so reader A and reader a are different readers. This test is added to check if this feature is maintained. Developers should remove this test if case sensitivity changes.

Circular tag sets and circular reader roles

Circular definitions of tag sets and roles in tag files and reader files are definitions like this.

reader A
{
      A,
}

These definitions are illegal because they could cause confusion. But these are possible input mistakes by RFID Guardian users. So the standard error stream is filtered for MRG error messages, such as Cannot lookup reader and Cannot locate tag set. If the script encounters these messages, the software passes this test.

Deny has a higher priority

the current implementation of MRG is that it will not depend on the anti-collision algorithm for protecting tags. Suppose that there are two tags: Tag A (0x010101010101) and Tag B (0x000000001), which are both contained in a large group called MYTAGS. If the ACL is as follows:

rule P15693 DENY
{
	tags = @MYTAGS;
	role = *;
};
rule P15693 ACCEPT
{ 
	role = LEGAL_READER; 
	tags = $$TAG_A;
};

Then when a legal reader is querying tags like this

query P15693
{
	command = INVENTORY;
	mask_len = 1;
	mask = 0x1;
};

Then both tags should match this query because their last tag id both end with 1. So both tag A and B will respond. According to rule No. 2, RFID Guardian should allow this query, because it is the legal reader who is doing query; however, RFID Guardian should deny this query as well, because according to rule No. 1, tag B is what RFID Guardian should protect. Some may argue that RFID Guardian does not have to take any action, because when responses from both tags arrive at the reader the reader will get confused and automatically start the anti-collision process. However the software developers decided that MRG should deny this query anyway. Their justification was that although the software decides actions based on the tag files, this tag file may be not up to date. In this example, tag B may be just out of range, or it might even have been left at home. Therefore, they cannot depend on the anti-collision algorithm to take effect. For the test, this principle is called ``Deny has a higher priority, because when implemented in this way, RFID Guardian is going to deny queries as much as it can.

different request

In this test case, software is checked to see if it could recognize different kinds of RFID query request, including inventory, write single block and write multiple block.

does star work

there are some rules written with a star (*), where star means `any'. For example,

command = *  

This test contains two different ACL files and these files are tested in turn (option ``-a specifies which ACL file should be used for testing). After filtering the output stream, the exact number of denials or acceptance messages are checked.

empty rules, tag sets and roles

To test if the software will crash if tag sets and roles are empty, and if they will influence the ACL decision. We observe some time ago, that the software will crash if there is an empty rule in the ACL file, so these tests are added ensure that this bug is fixed permanently.

explicit inventory

a previous version of the software had the behavior that if the user writes the ACL to deny all kinds of queries,

rule P15693 DENY
{
   role = role1;
   command = *;
   tags = @TAGS1;
};

then the software behavior was correct. However, if the user specifies that only the inventory query should be denied,

rule P15693 DENY
{
   role = role1;
   command = INVENTORY;
   tags = @TAGS1;
};

then the inventory request was allowed! This test ensures that the bug does not reoccur.

explicit multi

another bug was that if the ACL was to deny inventory, and then allow write single block request, the software would automatically deny a subsequent write multiple blocks request, which is of course incorrect. This test was added to ensure this bug stays fixed.

nested rule, role and tagsets

When roles and rules are declared nested like below:

rule ACCEPT
{
	rule ACCEPT
	{};
};

the software will complain about grammar error. But the software does allow nested tag sets, For example,

@tag P15693 MYTAGS
{
       tag P15693 = { tagid = 0xE0123456; },
       @tag P15693 = { store = xxx },
};

This test is to check if the software accepts this kind of input.

@tag P15693 MYTAGS
{
	@tag P15693 { 
		tag P15693 = { tagid = 0xE0123456; },
	},
};

Result shows it is not allowed.

priority

there is an optimization algorithm for MRG to achieve high e±- ciency, which is explained further. This test is to check if this optimization algorithm still works.

X include Y

Here, X could be single reader, roles, single tag or tag sets. These tests are useful because sometimes people use the same name to declare different identities, which costs confusion to RFID Guardian. Some tests are done to check if the software will find same information in its naming space. The key words used here include: Cannot add role, Cannot create new tag list, Cannot add reader and Tag name already in use.

reader or tag on the same line

a previous version had a bug whereby if readers were added to roles in a same line (instead of in separate lines), like this,

reader A {};
reader B {};
role C
{
	A, B,
};

then decision of the software was not determined. This test ensures this mistake stays corrected. Furthermore, an extra test sees what would happen if tags are added to tagsets in the same line.

same X declared twice

Here, X could be single reader, roles, single tag or tag sets. These tests are useful because sometimes people use the same name to declare di®erent identities, which costs confusion to RFID Guardian. Some tests are done to check if the software will find same information in its naming space. The key words used here include: Cannot add role, Cannot create new tag list, Cannot add reader and Tag name already in use.

simplest accept

There is only one tag, one reader and the acl file simply allows the reader to query the tag. This is the simplest scenario, and the software should always pass this test.

simplest deny

Almost the same as Simplest accept except that the acl file denies query request.

superset role or tagsets

sometimes people make mistakes by writing A is a superset of B is a superset of A, like below:

role A
{
     B,
};
role B
{
     A,
};

So this test checks whether MRG could be fooled by this kind of input.