Three types of data encryption standards for WiMAX networks

When data is transmitted and received over WiMAX Wireless infrastructure they can use many types of encryption methods below I will quickly highly 3 types of encryption standards that can be used with WiMAX.


  • Advanced Encryption Standard (AES) with 128-bit key
  • Rivest, Shamir and Adleman (RSA) with 1024-bit key
  • Triple Digital Encryption Standard (3-DES)


Both Advanced Encryption Standard (AES) and Triple Digital Encryption Standard (3-DES) are symmetric encryption algorithms using a block-cipher method.

Screen Shot 2017-09-29 at 8.03.46 am.png

Figure 1: Symmetric-Key Encryption

Where Rivest, Shamir and Adleman (RSA) is an asymmetrical algorithm. The main difference between symmetric and asymmetric encryption algorithms is that with symmetric encryption both keys are the same for encryption and decryption an unlike asymmetric encryption which uses two different keys.

Screen Shot 2017-09-29 at 8.01.14 am.png

Figure 2: Asymmetric-Key Encryption

 AES with 128-bit key was developed by the National Institute of Standards and Technology (NIST) in 2001 it used the Rijndael algorithm, it was designed to replace Digital Encryption Standard (DES) AES is the one of the most secure encryption standards in used today.

Screen Shot 2017-09-29 at 8.00.55 am.png

Figure 3: Advanced Encryption Standard

Triple Digital Encryption Standard (3-DES) encrypts its data three times with a 56-bit key. It is not as secure as AES, as such AES meant and designed to replace 3-DES.

Screen Shot 2017-09-29 at 8.01.06 am.png

Figure 4: Triple Digital Encryption Standard

RSA developed in 1977 is an asymmetrical algorithm that uses a public and a private key, one key is used to encrypt the traffic and the other key is used to decrypted. RSA is mainly used today for authentication, it can have key lengths of up to 2048 of which 1028 is the average size. Asymmetrical algorithms such’s as RSA require more CPU overhead to generate and maintain compared to Symmetrical algorithms like the ones mention.

Screen Shot 2017-09-29 at 8.00.47 am.png

Figure 4: RSA Encryption

All of the encryption standards mentioned provide confidentiality by turning clear text into cipher text.

Screen Shot 2017-09-29 at 8.05.18 am.png


Critical reflection on the topic of Energy Harvest for wireless Communication systems

 In following paragraphs, I will provide my critical reflection on the topic of ‘Energy Harvest’ after reading the following white papers.

Shaikh, Faisal Karim, and Sherali Zeadally. “Energy harvesting in wireless sensor networks: A comprehensive review.” Renewable and Sustainable Energy Reviews 55 (2016): 1041-1054.

Ulukus, Sennur, et al. “Energy harvesting wireless communications: A review of recent advances.” IEEE Journal on Selected Areas in Communications 33.3 (2015): 360-381

Both authors have addressed the different techniques of energy harvesting, hardware design requirements as well the efficiency and advances in technology required to be able to make this a viable option for wireless sensor networks (WSN).

While the concept of energy harvesting is an excellent idea and a possible solution to many of the issue that plague remote wireless senor networks, both authors admit it is still in its infancy, due to technology constraints and manufacturing cost.

The issue I see still being a problem in the future is the dependency on a battery backup in the event that its main energy source is not available as well as the requirement to perform on-going maintenance work on the energy harvesting equipment.

I have experience when it comes to the deployment, installation and maintenance of wireless sensor networks, coming from the mining section, we use WSN to relay information form Programmable Logic Controllers (PLC) that are connected to remote monitoring equipment or machines. While the idea of being able to deploy these in a small form factor devices in a set and forget mind-set dependant on the life span of the equipment is great, what I have found given my experience is that the main issue is actually the energy harvesting device whether it be solar panels or wind turbine that supplies the power as well as tickle charges the battery in the event that the sun or wind is not available, requires more on-going maintenance then the actually battery or WSN.

The ongoing maintenance involves cleaning due to excess dust build and animal excrement on the solar panels, the wind turbines require lubrication and at times both energy harvesting devices required replacement due to the extremes of weather or damage cause by animals or birds.

In some case the actually WSN and external battery out lives the energy harvesting equipment, the main reason for this is because it is shelter from the extremes of weather and animals.

While I hold a common interest in being able to power WSN by means as described in the research papers as well as reduce maintenance requirements where possible, I believe we are some time off before this is a reliable and cost-effective solution for most consumers to purchase and even then, given the certain environments that WSN are could be reduced in, it will still require on-going servicing of the energy harvesting equipment to ensure a long-life span.

Security challenges for Bluetooth and ZigBee WPAN technologies

One would think given the short range, low power and low data rates offered by WPAN technologies such’s as Bluetooth and ZigBee devices that it would not present much of a security concern, yet they are still prone to attacks as they can allow hackers a backdoor into certain networks.

ZigBee has the ability to use symmetric encryption algorithm meaning they use the same key to encrypt and decrypt. Bluetooth devices also have encryption options available however due power saving features, slow on-board CPU’s as well as the extra overhead generated by the encryption process. Encryptions ends up being rarely used, so when devices are joining and establishing connectivity all data is sent in clear text and is readable on the air waves for anyone in close proximity with the right tools to capture and decode.

ZigBee uses two types of symmetric keys for encryption: the network and link key.

When a device requests a link key to setup a secure connection between device in the piconet. A link key which is based on the network key is generated and encrypted with the network key, this must occur before the trust centre (PNC) distributes it to other devices on the piconet. This method allows vulnerability to the lower layers as it only applies to layer 7 (Application layer).

Bluetooth devices use a mechanism called pairing, which is a two-step process that enables the discover and connection of nearby devices. The Pairing process allows hackers with opportunity to discover and transmit unsolicited message to devices in close proximity this type of attack is known as bluejacking.

Another attack known as Bluesnarfing also leverages of the pairing process, enabling hackers access to information contained within personal smart devices, this type off attack can occur without the knowledge of the owner, if the user has enable certain settings on the device.

Bluetooth devices are prone to a very common security threat across all communication technology platforms called Denial-of-service (DoS) this attack renders the device useless as it not able to process all the malicious information that is being sent to it.

Bluetooth devices present many security concerns, not only from their own security vulnerabilities but it also allows hackers to user Bluetooth device for their own gain. Given their small form factor, low cost of manufacture, a hacker could easily plug a USB Bluetooth device into the back of a desktop without a user being aware, and given small form factor, low power and use of FHSS it makes them hard to discover or located, even with a spectrum analyser one would still have to in closer proximity of the device and be able to identity the signal pattern.

Another security concern is jamming of the RF spectrum, given both technology operate in the 2.4GHz band a hacker may not want to steal information but render the devices un-reusable but deploying a wireless jammer, commonly known as an ‘Air horn’.

A hobbyist company called Hak5 makes devices that have the potential to be used for malicious reason if in the wrong hands, in particular it has Bluetooth packet sniffer this could be used to capture and decode frames for malicious reason.

L. Olenewa (2014). Guide to Wireless Communication (Third Edition). Boston: CENGAGE Learning

Cisco Load Balance configuration



Cisco Load Balance configuration

More detail explanations can be found a


Sometime referred to as advanced Load Balancing (Load balancing +). Is an enhancement to Aggressive load balancing, it allows you to configure load balancing per WLAN. Feature is disabled by default


Feature load balances wireless clients across Access point. Clients are only able to be load balanced across access points on the same WLC. Load balancing does not occur between access points on different controllers.


Load balancing only works at the association phase.


when a client tries to associate to a Cisco Lightweight Access point, association response packet is sent to the client with an 802.11 response packet including status code 17. The code 17 indicates that the AP is busy, so the client has to look for another AP to associate with.


The AP responds with association response bearing “success” if the AP threshold is not et, and with code 17(AP busy) I the AP utilization threshold is reached or exceed and another less busy AP heard the client request.


Problem can arise, if AP discarded or sends a status code 17 to client then client have to decide to ignore it or still use the same AP. Some client driver uses the same AP for connection once again but most of the other type of clients tries to find other AP for connection. So it depends on vendor drivers, as you cannot force them to accept the status code 17.


It is recommend not to enable this feature for the voice WLAN as it can cause roaming issues. For other WLANs, it should be enabled only after testing.


      • Client Window size: the client size window and client n least loaded AP determine the load balance threshold value.

Before configuring the load balance intelligence, remember the formula. An AP is considered busy once it has a number of associated clients equal to the client windows size plus the number of clients on the least loaded AP in the area

Load-balancing threshold= client window size + number of clients on the least loaded AP


Example: 3 AP

AP1: 9 clients

AP2: 7 clients

AP3: 4 clients


As per last default settings on last screen shoot client window size is 5

As per formula, load balance threshold is =5+4=9

Means if any new client wants to join AP1 then client will get the status 17(busy) message or in other words this AP(AP1) is considered to be busy.

      • Maximum Denial count: the maximum denial count parameter allows the user to configure the number of times the client associations will be rejected for a particular AP. The maximum denial count can have a value between 0 and 10


Network configuration

Form GUI:

Screen Shot 2017-09-02 at 7.37.41 pm.png

Figure 1. Client Load balancing global configuration windows

Screen Shot 2017-09-02 at 7.37.50 pm.png

Figure 2. Client Load balancing configuration per WLAN

Form cli:

Screen Shot 2017-09-02 at 7.37.58 pm.png

Figure 3 Client Load balancing configuration options

Screen Shot 2017-09-02 at 7.38.06 pm.png

Figure 4. Client Load balancing window


Screen Shot 2017-09-02 at 7.38.12 pm.png

Figure 5. Client Load balancing denial count

Screen Shot 2017-09-02 at 7.38.18 pm.png

Figure 6. enabling Client Load balancing configuration

Screen Shot 2017-09-02 at 7.38.24 pm.png

Figure 7. Disabling WLAN inference

then enable Client Load balancing by # Config plan load-balance allow 1

Screen Shot 2017-09-02 at 7.38.30 pm.png

Figure 8. enable WLAN inference
Screen Shot 2017-09-02 at 7.38.36 pm.png

Figure 9. Displaying Load balancing information


Screen Shot 2017-09-02 at 7.38.43 pm.pngScreen Shot 2017-09-02 at 7.44.54 pm.png

 Figure 10. Displaying WLAN configuration information

Kali Linux, putting WiFi Card into monitor mode

This is guide is about how to put your wireless adapter into monitor mode, using Kali Linux and then use Wireshark to inspect the frames (Wireshark comes standard with Kali)

*Not all wireless cards(chipsets)support monitor mode if unsure do a google search.    For this I will be using a Alfa Networks card:AWUS036NH.

Step1: check that the NIC is attached type

Screen Shot 2017-09-01 at 4.52.57 pm.png


Screen Shot 2017-09-01 at 4.53.05 pm.png

Step2: Place wireless interface in monitor mode Airmon-ng start <interface name>  Screen Shot 2017-09-01 at 4.53.09 pm.png

Step 3: kill an process that are currently running.  Screen Shot 2017-09-01 at 4.53.17 pm.png

then check that processes have been stopped

Screen Shot 2017-09-01 at 4.53.23 pm.png

Step 4: Put interface  in sniffing mode this command will scan over all channels  depending on  wireless device chipset

Screen Shot 2017-09-01 at 4.53.28 pm.png

Can just sniff on a specific channel with the following command

Screen Shot 2017-09-01 at 4.53.39 pm.png

Screen Shot 2017-09-01 at 4.53.33 pm.png

Once sniffing channels load Wireshark, in in root access you will be presented with the below error message press ok and the select the wlan0mon interface to load the 802.11 frames.

Screen Shot 2017-09-01 at 4.53.51 pm.png