Using Perimeter Detect: Zymkey 4


This section explains the perimeter detect feature on Zymkey 4i and how to use it in your software application with a simple two wire loop physical configuration.

For alternative physical configurations and best practices: Learn more >

Perimeter Detect provides two additional layers of physical security that can be used to detect when the perimeter of your device is breached. This is an important feature when devices are deployed in the field, unattended or in high risk environments.

Zymkey 4i includes two independent Perimeter Loops that can be configured to meet different applications.

When a Perimeter Loop is breached, Zymkey 4i can be configured (at time of binding) to respond with different “Actions”, depending upon your security policy.

Connecting Perimeter Loop Circuits

Zymkey 4i uses a standard microUSB connector to interface to perimeter circuits 1 and 2. This is convenient for rapid prototyping and small scale production situations.

(For high volume applications, different connector types are available. Contact Zymbit for more details.)

Using a Standard USB EXTENSION Cable for Perimeter Loop

You can use a micro-usb EXTENSION cable, which carries all necessary signals, to connect to the perimeter detect. Here is one example of an extension cable that will work. (Remove the female connector to expose the flying leads as shown below, then connect your perimeter circuits - P1, P2 - to these)

IMPORTANT: do NOT use standard micro-usb charging cable it will not work, because it does not have a wire on pin 4.

Electrical Circuit

Each perimeter loop should be connected with a 30 AWG wire or thicker and nominal length of 2 feet. For longer lengths contact Zymbit. The wire should be electrically insulated for all applications. A shielded cable may be necessary for electrically noisy or industrial applications.

Custom flex PCBs and rigid PCBs may also be used to complete a perimeter loop circuit.

Perimeter Breach Response Actions

Prior to permanently binding your Zymkey to a specific host device, it can be configured through the API to respond to a perimeter breach event in one of three ways. After permanent binding is completed, the selected configuration is locked and immutable.

Response Choices

A) Do nothing (disable)
B) Notify host when perimeter breach occurs
C) Destroy all key material (this essentially destroys any encrypted data or file system)

Refer to API documentation for more details.

Test Perimeter Detect (Developer Mode only)

To quickly test your perimeter detect setup, here are two samples of code using the Python and C API’s. Both programs will wait for one second to detect any perimeter breaches.

Please specify the channel (0 or 1) you are testing in either set_perimeter_event_actions or zkSetPerimeterEventAction. Currently the channel is set to 0. In the API, perimeter circuit 2 (as shown in the above images) is defined as channel 1 and perimeter circuit 1 is defined as channel 0.

For Python

import zymkey

zymkey.client.set_perimeter_event_actions(0, action_notify=True, action_self_destruct=False)

  perim_status_str = ""
  idx = 0
  plst = zymkey.client.get_perimeter_detect_info()

  for p in plst:
    if p:
       perim_status_str += "Channel %d breach timestamp = %d\n" % (idx, p)
    idx += 1
  print("Perimeter breach detected!\n" + perim_status_str)

except zymkey.exceptions.ZymkeyTimeoutError:
  print("No perimeter breach detected.")


For C

#include <stdio.h>
#include "zk_app_utils.h"

void check_code(int code, char* location)
  if (code < 0)
    printf("FAILURE: %s - %d\n", location, code);
  else if (code >= 0)
    printf("SUCCESS: %s - %d\n", location, code);

int main()
  zkCTX zk_ctx;
  int status = zkOpen(&zk_ctx);
  check_code(status, "zkOpen");

  status = zkSetPerimeterEventAction(zk_ctx, 0, ZK_PERIMETER_EVENT_ACTION_NOTIFY);
  check_code(status, "zkSetPerimeterEventAction");

  int p_code = zkWaitForPerimeterEvent(zk_ctx, 1000);
  check_code(p_code, "zkWaitForPerimeterEvent");

  uint32_t* timestamps_sec;
  int num_timestamps;
  status = zkGetPerimeterDetectInfo(zk_ctx, &timestamps_sec, &num_timestamps);
  check_code(status, "zkGetPerimeterDetectInfo");

  //There was a perimeter event/breach.
  if (p_code == 0)
    printf("Perimeter breach detected!\n");
    for(int i=0; i<num_timestamps; i++)
      printf("Channel %d breach timestamp = %d\n", i, timestamps_sec[i]);

  status = zkClearPerimeterDetectEvents(zk_ctx);
  check_code(status, "zkClearPerimeterDetectEvents");

  status = zkClose(zk_ctx);
  check_code(status, "zkClose");
  return 0;

To compile

gcc -I /usr/include/zymkey/ -l zk_app_utils <Your Program>

If the perimeter is not breached, zkWaitForPerimeterEvent will return a failure code indicating a timeout occurred and no breach was detected.

SUCCESS: zkOpen - 0
SUCCESS: zkSetPerimeterEventAction - 0
FAILURE: zkWaitForPerimeterEvent - -110
SUCCESS: zkGetPerimeterDetectInfo - 0
SUCCESS: zkClearPerimeterDetectEvents - 0
SUCCESS: zkClose - 0

Perimeter Detect Circuit Examples

For best practices and examples of how to physically configure perimeter circuits:
Learn more>


I am very interested by the zymkey 4i product, especially by the physical tamper protection.

But I have few question:

I readed in the RTC tutorial that the coin cell only serves for the RTC, does it mean than the perimeter detection is only working when the zymkey is powered on thanks to my raspberry? In this case, how to protect from an attacker who would destroy the “enclosure” of my system while it is powered off, and also the perimeter two perimeters loop circuits? I mean, in “therory”, I guess it could easily identify the zimkey, and juste put two illegitimate loops circuit in the receptacle, to fake the zimkey before to put the system on again. Am I wrong? or maybe I am missing something?

In this case, does it mean the perimeter features is “nothing” without a strong “physical” protection like expoxy on the SD and the zymkey? So why to not use the coin cell to make the perimeter protection always activated?

By the way, is it possible to extend the RTC battery life, for example if I put many CR2032 coins in parallel?

And to finish, do you know when you could be able to release application examples and dev kits for the perimeter detection?

Thanks by advance!

By the way, your product looks really cool, good job!

Hi Tgratier,

  1. Perimeter detect does already work with battery backup, Otherwise, as you point out, its pretty useless. The Pi, Zymkey and Battery should be enclosed in one or both of the perimeter loops.

  2. Zymkey 4i is designed to accept CR1025 coin cells, with nomimal lifetime of 1.5 years (host not powered), 3-5 years (host powered 75% of time). There is no mechanical provision for larger coin cells, but electrically if you wanted to hot wire a larger battery of the same voltage, that should work, with some caveats. We do have some OEM products in the works that will allow the user to apply an ‘external battery’. Contact Zymbit to discuss the specifics of your application in more detail.

  3. We will release some application notes for perimeter detect in a couple of weeks. (Sept 21).

Thanks for your interest.

1 Like

Ok thanks for the quick answer! I am glad to see I was misunderstood haha.
And sorry for my mistake about the coin model.

No apologies required. We are hear to help !

do you have any news about some applications notes release for perimeter detect?
Thanks by advance :slight_smile:


Putting together a general use case app note always takes longer than a specific use case, so sorry for the delay. We should having something up next week.

If you have a specific use case and need answers now then please contact us here

Ok cool, I will wait!
Thx :slight_smile:

From the initial specs I read “Optional accelerometer detects shock and orientation change events”. How can I use acceleromoter? Is this one of the two perimeters loops? What means optional? I am interested in ZYMKEY 4i.

If you bought the Zymkey 4i, the accellerometer comes as standard.

You will find details of how to use the accellerometer in the documentation, here: API Documentation

zymkey 4i 3i feature matrix 1707

Thanks, I understand acceleremeter is device integrated and doesn’t use(occupies) any of the two perimeter loop circuits
From introduction I also read “Power rail monitor detects anomolies like brown-out events”. I can not find any reference in the API documentation, can you tell me where to read about? Is this the mechanism used by perimeter loop system or something I can check from the API?

Your Zymkey contains three different layers of Tamper Detection. Each operates independent of the other:

  1. Accellerometer - accessible through API
  2. Perimeter detection loops x 2 - accessible through API
  3. Power rail monitor - for internal defense only. NOT accessible through the API

While waiting for the sample app, if USB is open (nothing connected) and run a script with these commands, should event happen?:
zymkey.client.wait_for_perimeter_event ()

I forgot to configure notification:
zymkey.client.set_perimeter_event_actions ( channel = 1, action_notify = True , action_self_destruct = False )

Happy to hear you found the solution.


it’s me again, for few questions.

I am trying to execute a periodic check of the PERIM1 circuit.
The code below works well during first rounds, but suddenly the breach action is not anymore detected.
After few minutes, it start to work well again, etc. If I reboot the pi, the code will works directly (during few rounds again).

I simply connect a USB cable with white and black wires connected, and make them touch themselves during the tests. I can’t see anything wrong in /var/log/syslog.

Is this my routine code which is not the best way to check the perimeter loop? Why is my zymkey just “stop to work” during few minutes? Should I use “zkWaitForPerimeterEvent(ctx, 0);” ?

By the way, in the code below the “num_timestamps” value is ALWAYS equal to “2”. Why 2 whereas I only set an action for the PERIM1 circuit and not PERIM2?

Thx by advance.

int num_timestamps = 0;
uint32_t *tab_event;
zkCTX ctx;

if(zkOpen(&ctx) <0)
	printf("Unable to setup RTC module\n");
	return 0;
zkSetPerimeterEventAction(ctx, 0, ZK_PERIMETER_EVENT_ACTION_NOTIFY);

	 *	do_something

	zkGetPerimeterDetectInfo(ctx, &tab_event, &num_timestamps);
	if(num_timestamps > 0)
		printf("num timestamp = %d\n", num_timestamps);
		printf("Last event = %ld\n", tab_event[0]);
		zkLEDFlash(ctx, 500, 500, 4);
		num_timestamps = 0;