6  Selfish and Malicious Nodes

iot
wireless-sensor-networks
sensor-nodes
Keywords

selfish nodes, malicious nodes, sensor node behavior, forwarding evidence, behavior classification, node review record

6.1 Start With the Field Story

A bad node is not just a security word. In a WSN it may save its own battery, drop other nodes packets, impersonate neighbors, attract routes, or tunnel traffic through a false shortcut. Start by naming the behavior you can observe before choosing a defense.

6.2 In 60 Seconds

Selfish and malicious nodes can look similar at first because both can withhold, delay, or distort traffic. The difference is not proven by a single missing message. It is a classification question: what behavior is visible, what benign explanation has been checked, and what action protects the affected decision while uncertainty remains?

A selfish-node hypothesis fits when a node continues to protect its own traffic but avoids shared work such as relaying, route participation, or cooperative sensing. A malicious-node hypothesis fits when the evidence shows active disruption, identity inconsistency, false route claims, or data manipulation that is not explained by ordinary limits.

6.3 Learning Objectives

By the end of this chapter, you will be able to:

  • Distinguish selfish behavior from malicious behavior using observable evidence.
  • Build a review record for forwarding, route, identity, and data-integrity concerns.
  • Check benign explanations before assigning an intent-heavy label.
  • Choose a bounded mitigation that matches the evidence rather than the most dramatic possibility.
  • Define retest triggers that confirm whether the classification should stand, change, or close.

6.4 Quick Check: Selfish & Malicious Nodes

6.5 Minimum Viable Understanding

  1. Selfish and malicious labels are hypotheses supported by evidence, not guesses about motive.
  2. Selfish behavior usually preserves the node’s own traffic while avoiding shared duties.
  3. Malicious behavior usually introduces active disruption, false claims, identity conflict, or data manipulation.
  4. Classification should record the expected role, observed behavior, corroborating views, benign checks, action, confidence, and retest trigger.
  5. The response should be narrow enough to protect the affected decision without turning a weak signal into a permanent label.

6.6 Prerequisites

6.7 Classification Scope

This chapter is about behavior classification. It does not try to cover every harmful pattern, and it does not prescribe a full operational playbook. Keep the review focused on the evidence the system can observe:

  • expected role and message obligations;
  • own-traffic behavior compared with relay behavior;
  • route claims compared with independent path evidence;
  • identity consistency across messages and neighbors;
  • value integrity and whether related evidence contradicts the data;
  • changes after monitoring, schedule changes, or reduced relay duty;
  • remaining uncertainty and the next evidence that should reopen the review.

The label should be useful to the next routing or validation decision. If the evidence is thin, use a suspect or unknown label from the broader classification chapter instead of claiming intent.

6.8 Evidence Map

Use the same evidence record for both selfish and malicious hypotheses. The difference is how the evidence fits together.

Evidence map where expected role, observed behavior, corroborating views, and benign checks feed a selfish-or-malicious classification hypothesis, then a mitigation fit and a retest trigger.
Figure 6.1: Evidence map for classifying selfish and malicious nodes: expected role, observed behavior, corroborating views, and benign checks converge on a classification hypothesis, then a mitigation fit and a retest trigger.

Figure 6.1 keeps the review tied to observable facts:

  • Expected role: Was the node expected to sense, forward, advertise a route, acknowledge receipt, or validate a neighbor?
  • Observed behavior: Which expected messages, relays, acknowledgements, or values are missing or inconsistent?
  • Corroborating views: Do related nodes, path records, or gateway logs support the same pattern?
  • Benign checks: Could schedule, queue pressure, radio conditions, restart state, or limited diagnostics explain the behavior?
  • Classification hypothesis: Does the evidence fit selfish behavior, malicious behavior, suspect behavior, or unknown?
  • Mitigation fit: Does the chosen action address the observed risk without assuming more than the record supports?
  • Retest trigger: What new evidence should confirm, change, or close the label?

6.9 Distinguishing Selfish From Malicious

Selfish behavior is a cooperation problem. The node may still report its own readings and may still use the network for its own messages, but it avoids duties that mostly benefit others. Reviewers should look for asymmetry: own traffic succeeds while relay duties, shared sensing, or route participation are repeatedly weak.

Malicious behavior is a harmful-interference problem. The node may make claims that conflict with independent evidence, change data that should remain stable, present inconsistent identity information, or attract traffic without supporting the promised role. Reviewers should look for contradiction and active harm rather than ordinary absence.

Useful distinctions include:

  • Own traffic versus shared duty: Selfish behavior often preserves own traffic while avoiding shared work. Malicious behavior may disrupt either own or shared traffic if it advances the harmful pattern.
  • Response to observation: Selfish behavior may improve when relay obligations are visible or when shared load is reduced. Malicious behavior may continue despite those checks.
  • Evidence shape: Selfish behavior often appears as repeated non-participation. Malicious behavior often appears as false claims, identity conflict, selective distortion, or route manipulation.
  • Benign explanation: Both hypotheses require a check for ordinary causes before the label is assigned.

Do not make motive the first step. Start with behavior, then decide which hypothesis best explains the record.

6.10 Cooperation Incentives and Enforcement

Selfish forwarding is a cooperation problem. A node can save energy by dropping relay traffic while still using other nodes to carry its own packets. If enough nodes do that, the multi-hop network loses the shared forwarding capacity it depends on.

That means detection alone is not a complete control. A watchdog can overhear that a next hop did not forward, and a pathrater can route around that next hop. That protects the affected path, but it can also reward the free rider if the node is now excused from relay work while its own traffic still moves through other neighbors. Deterrence requires a consequence that makes cooperation the better local choice.

Sensor behavior trust review loop from expected role through observations, evidence checks, trust update, bounded action, and retest trigger.
Figure 6.2: Sensor behavior trust review loop from expected role through observations, evidence checks, trust update, bounded action, and retest trigger.

Use Figure 6.2 to keep trust local and reversible: compare the expected role with the observation record, check ordinary explanations, update the score or label only for the affected decision, choose a bounded action, and name the evidence that can revise or clear the label.

Common cooperation mechanisms differ in what they make visible:

Mechanism What it observes What changes
Watchdog A neighbor overhears whether the next hop forwards a packet it received. The review gains evidence about relay compliance.
Pathrater Routing uses watchdog evidence to avoid persistent non-forwarders. Traffic can move around a weak relay path.
Reputation or trust score Repeated forwarding, acknowledgements, role evidence, and benign checks update a local score. Low-trust nodes lose service or are avoided for the affected role.
Credit or virtual currency A node earns credit by forwarding and spends credit to send its own traffic. Forwarding becomes a prerequisite for using the network.

Keep the counts separate: own packets sent, relay packets received, relay packets overheard as forwarded, link-quality samples, queue-full events, restart evidence, and sleep-state evidence. If a node has 30 relay opportunities, forwards 4, and still delivers 12 of 12 own packets while link and queue records stay normal, reputation should fall for the relay role. If the same node has a low-battery alarm and queue overflow during a known interference window, the safer label may remain suspect until the pattern repeats after recovery.

Credit systems make the incentive arithmetic explicit. A policy might charge one credit to inject an own packet and award one credit for forwarding a neighbor’s packet. A node that wants to send 20 of its own messages must forward roughly 20 qualifying packets or receive a documented maintenance allowance. That does not prove honesty, but it removes the free-rider option where a node consumes network service while contributing nothing to shared routing.

Malicious behavior needs stronger controls because an attacker may accept personal cost to damage the network. A sinkhole or wormhole can forward enough traffic to preserve reputation while bending topology or observing data. Pair cooperation enforcement with route-metric validation, authenticated identities, multipath checks for critical traffic, and time-decayed evidence so old good behavior cannot permanently mask recent harm.

6.11 Knowledge Check: Cooperation Enforcement

6.12 Common Attacks and Effects

Behind the behavior labels are a handful of well-known node attacks. Name them so you can recognize the evidence pattern each one leaves.

Selfish (free-riding). The node uses the network for its own traffic but skips relay duty to save energy — it silently drops packets it was supposed to forward. Evidence: own messages succeed while relay counts stay low. Defense: a watchdog (neighbors overhear whether a node actually forwards) feeding a reputation/trust score that routes around persistent free-riders.

Blackhole. The node advertises an attractive route — often “shortest path to the sink” — to pull traffic toward itself, then drops everything it should forward. Evidence: high advertised route quality but near-zero delivery through it. Defense: multipath routing, a watchdog, and end-to-end acknowledgements.

Sinkhole. A variant that lures a whole region’s traffic by advertising an unusually good link to the base station, making itself a routing hub — usually a setup for dropping or tampering. Defense: authenticated routing metrics and geographic routing that does not trust advertised cost alone.

Selective forwarding (gray-hole). The subtlest: the node forwards most packets to look healthy but drops targeted ones — e.g. alarm messages — so simple delivery-rate checks miss it. Defense: multipath so critical messages have a second route, plus per-flow acknowledgement monitoring.

Sybil. One physical node fabricates many identities to stuff reputation votes, win routing decisions, or defeat redundancy (every “replica” you trusted is really one attacker). Defense: bind identity to a key, or a radio-resource test so one node cannot cheaply mint many.

Wormhole. Two colluding nodes open an out-of-band tunnel and replay each other’s packets, so distant nodes believe they are neighbors — distorting the topology and hijacking routes. Defense: packet leashes (geographic or tightly time-synced bounds) that reject links that are “too far, too fast” to be real.

On-off (conflict) behavior. A node behaves well long enough to earn trust, then attacks intermittently. Defense: time-decayed reputation, so old good behavior cannot indefinitely mask recent harm.

6.13 Review Workflow

The review loop keeps classification conservative. It starts with what the system expected, checks what actually happened, and ends with a retest trigger rather than a permanent judgment.

Review loop for selfish and malicious node classification from observe path, compare role, check benign causes, classify behavior, choose bounded action, and retest trigger.
Figure 6.3: Review loop for selfish and malicious node classification from observe path, compare role, check benign causes, classify behavior, choose bounded action, and retest trigger.

Use Figure 6.3 when a node’s behavior affects a routing or data-validity decision:

  1. Observe path: Record the messages, relays, acknowledgements, route claims, and data values seen by the monitor.
  2. Compare role: Check those observations against the node’s assigned role and expected schedule.
  3. Check benign causes: Look for ordinary explanations such as scheduled sleep, restart, queue pressure, weak link evidence, or limited diagnostics.
  4. Classify behavior: Assign selfish, malicious, suspect, or unknown with confidence and evidence.
  5. Choose bounded action: Reduce reliance, avoid the relay path, request corroboration, or quarantine the affected data path as appropriate.
  6. Retest trigger: State the next observation that would confirm, downgrade, or clear the label.

6.14 Production Trust Record

The merged production-review material turns classification into a release gate. A behavior rule is ready only when its evidence, label, action boundary, owner, and retest trigger can be reviewed together.

A production trust record should state:

  • decision context: route, data path, validation rule, or alert that depends on the label
  • expected role: forwarding, acknowledging, sensing, corroborating, or reporting status
  • observations and related checks, including stale, missing, contradictory, or corroborating evidence
  • benign explanations considered before assigning an intent-heavy label
  • local trust state, confidence band, or score rule if one is used
  • bounded action, such as reduce reliance, request corroboration, avoid a route, hold a value, or start recovery review
  • retest trigger that would restore, revise, downgrade, or close the decision

A score is not proof of motive, and a local threshold is not a universal property of sensor networks. Keep the action scoped to the affected decision while preserving unrelated evidence when it remains valid.

6.15 Worked Review: Relay Concern

Consider a node assigned as a relay for nearby sensors. The monitor sees that the node continues to send its own readings, but several neighbor paths show missing forwarded messages. Neighbor observations agree that the node receives relay requests. The schedule record shows no expected sleep period, and there is no recent role change.

Concrete example: in a warehouse mesh, a pallet-zone node reports its own temperature records on time but repeatedly fails to forward neighboring door and vibration records that it acknowledged receiving. That pattern supports a relay-behavior review; it does not by itself prove motive, tampering, or permanent exclusion.

The first review should not jump directly to intent. A review record should ask:

  • Did the node receive the messages it was expected to forward?
  • Did it forward some sources but not others?
  • Are its own readings still current and accepted?
  • Do related nodes see the same relay gap?
  • Does the pattern change when relay load is reduced or when forwarding is watched?
  • Is there conflicting identity, route, or value evidence?

A selfish-node hypothesis fits if the node protects its own traffic, avoids relay work, and improves when shared obligations are made visible or reduced. A malicious-node hypothesis fits if the node makes unsupported route claims, changes or withholds selected traffic in a way that does not fit ordinary constraints, or presents identity evidence that conflicts across observers.

The action should match the confidence. With moderate evidence, the review may route around the node for the affected traffic and keep collecting corroboration. With weak evidence, the better action may be a suspect label and a retest trigger.

6.16 Common Review Findings

Selfish behavior likely

  • Own readings remain present while relay work is repeatedly missing.
  • The node avoids route participation but continues to depend on other nodes.
  • Behavior improves after the monitor makes relay obligations explicit.
  • Reduced shared load changes the behavior in a way that fits resource preservation.

Malicious behavior likely

  • Route claims conflict with independent path evidence.
  • Identity information is inconsistent across observers.
  • The node receives traffic but selectively alters, suppresses, or redirects it.
  • Behavior does not improve after ordinary constraints are checked and controlled.

Still suspect or unknown

  • The observation window is too short.
  • Related nodes disagree about what happened.
  • Schedule, role, or restart records are incomplete.
  • The system cannot tell whether the node received the messages it failed to forward.

6.17 Limited-Capability And Recovery Cases

Some weak behavior is not selfish or malicious. A simple sensor node may be silent, recently restarted, unable to expose rich diagnostics, or returning with stored readings after a gap. Treat that as limited diagnostic evidence until the record supports a stronger label.

A recovery review should preserve:

  • the expected role and message schedule;
  • the last accepted observation and why it was accepted;
  • the missed-message evidence and whether the silence is isolated or shared;
  • any buffered data, including observation time, receive time, ordering, duplicates, and gaps;
  • the bounded recovery action;
  • the retest trigger that would clear, change, or escalate the label.

Useful recovery actions include waiting within a documented recovery window, retrying or requesting status, using fallback evidence while marking the original source unavailable, collecting stored data with freshness checks, or escalating review when the missing state outlasts the rule.

6.17.1 Worked Review: Silent Simple Node

Scenario: a simple condition node sends periodic readings to a gateway. The gateway stops receiving messages.

Concrete example: a bin-fill node has no rich diagnostics; it normally sends a fill-level record and battery flag to a gateway. When the record stops arriving, the recovery review should preserve the last accepted reading and show the current source as unavailable until a complete new record or validated stored record arrives.

Observation

The current reading is missing. The last accepted reading is no longer fresh enough for the application decision.

Evidence check

The monitor confirms the expected schedule, records the last accepted observation, and checks related sources. Related sources remain available, so the silence appears isolated.

Recovery action

The dashboard marks this source unavailable and uses a fallback evidence path for the affected decision. It does not reuse the stale reading as if it were current.

Retest trigger

Retest when the node sends a new complete reading, returns with buffered records, changes role, changes schedule, or remains silent past the review rule.

6.17.2 Returned Stored Records

Scenario: a simple node returns after a silent interval and sends stored readings.

Observation

The node is communicating again, but the records cover an interval when the gateway had no live messages.

Evidence check

The reviewer checks observation time, receive time, sequence order, duplicate handling, and missing intervals.

Recovery action

Fresh records may update the current decision. Older records update the history only if their validity checks pass. Missing intervals remain marked as missing.

Retest trigger

Retest if the node returns late again, if sequence gaps repeat, if duplicate handling changes, or if the recovered data conflicts with related evidence.

6.18 Knowledge Check

6.19 Matching Quiz

6.20 Ordering Quiz

6.21 Summary

Selfish and malicious node labels are useful only when they stay evidence-bound. Selfish behavior usually preserves the node’s own traffic while avoiding shared duties. Malicious behavior usually introduces active disruption, false claims, identity conflict, or data manipulation. Both labels require benign checks, corroboration, confidence, bounded action, and a retest trigger.

The safest review pattern is to classify behavior from what the system can observe, avoid claiming motive from a single symptom, and keep the action scoped to the affected routing or data-validity decision.

6.22 Key Takeaway

Selfish and malicious behavior must be handled through trust, monitoring, isolation, and recovery controls rather than assuming every node cooperates.

6.23 Concept Relationships

6.24 What’s Next

Previous: Sensor Node Behavior Classification for the evidence-first classification method that supports this chapter.

Next: Limited-Capability And Recovery Cases for review actions when a node is simple, silent, or unable to expose enough diagnostic evidence.