5.7 KiB
5.7 KiB
CCIP Security Guide for ChainID 138
Date: 2025-01-27
Network: ChainID 138 (DeFi Oracle Meta Mainnet)
Overview
This document outlines security measures, best practices, and audit considerations for CCIP infrastructure on ChainID 138.
Security Architecture
Access Control
Admin Functions
All CCIP contracts implement admin-only functions:
- Router:
addSupportedChain(),removeSupportedChain(),updateFees(),changeAdmin() - Bridges:
addDestination(),removeDestination(),updateDestination(),changeAdmin()
Security Measures:
- Admin address is set at deployment
- Only admin can modify configuration
- Admin can be transferred (with proper verification)
Oracle Functions
- CCIPSender: Only oracle aggregator can send updates
- CCIPReceiver: Only router can call
ccipReceive()
Replay Protection
Message Replay Protection
- Message ID Tracking: Each message has unique ID
- Processed Messages Mapping: Prevents duplicate processing
- Nonce Tracking: Per-user nonces for additional protection
Transfer Replay Protection
- Message ID Validation: Checks if transfer already processed
- Nonce Validation: Ensures ordered processing
- Source Chain Validation: Verifies message source
Security Best Practices
1. Admin Key Management
DO:
- Use hardware wallets for admin keys
- Implement multi-sig for admin functions
- Store keys securely (HSM, secure enclave)
- Rotate keys periodically
- Use separate keys for different functions
DON'T:
- Store private keys in plain text
- Use same key for multiple purposes
- Share admin keys
- Leave keys in version control
2. Configuration Security
DO:
- Verify all configuration changes
- Use testnet for testing changes
- Document all configuration changes
- Review changes before applying
- Monitor for unauthorized changes
DON'T:
- Make changes without verification
- Skip testing on testnet
- Allow unverified addresses
- Ignore configuration change events
3. Fee Management
DO:
- Monitor fee collection
- Set appropriate fee levels
- Withdraw fees regularly
- Document fee changes
- Alert on unusual patterns
DON'T:
- Set fees too low (risk of spam)
- Set fees too high (user impact)
- Ignore fee anomalies
- Leave fees uncollected
4. Destination Chain Security
DO:
- Verify destination chain selectors
- Validate receiver addresses
- Test destinations before enabling
- Monitor destination chain status
- Disable problematic destinations
DON'T:
- Add unverified destinations
- Use placeholder addresses
- Skip destination validation
- Ignore destination errors
Common Vulnerabilities
1. Reentrancy
Protection:
- Contracts use checks-effects-interactions pattern
- No external calls before state updates
- Replay protection prevents duplicate processing
2. Access Control
Protection:
- Admin-only modifiers on sensitive functions
- Router-only modifier on
ccipReceive() - Aggregator-only modifier on sender functions
3. Integer Overflow/Underflow
Protection:
- Solidity 0.8.19 has built-in overflow protection
- Safe math operations
- Input validation
4. Front-running
Protection:
- Nonce-based ordering
- Message ID uniqueness
- Transaction ordering protection (network-level)
Audit Checklist
Contract Security
- Access control properly implemented
- Replay protection in place
- Input validation on all functions
- Error handling comprehensive
- No reentrancy vulnerabilities
- Integer overflow protection
- Event emissions for all state changes
Configuration Security
- Admin key management secure
- Configuration change procedures documented
- Emergency procedures in place
- Monitoring and alerting configured
- Access logs maintained
Operational Security
- Deployment procedures documented
- Testing procedures in place
- Incident response plan ready
- Backup and recovery procedures
- Regular security reviews scheduled
Security Monitoring
Events to Monitor
-
Configuration Changes
DestinationAddedDestinationRemovedDestinationUpdatedAdminChanged
-
Unusual Activity
- High volume of failed messages
- Unusual fee patterns
- Configuration changes outside business hours
- Access from unknown addresses
Alerts
- Critical: Unauthorized configuration changes
- High: High failure rate
- Medium: Unusual activity patterns
- Low: Configuration changes (informational)
Incident Response
Security Incident Types
-
Unauthorized Access
- Detect: Monitor admin function calls
- Respond: Revoke access, investigate
- Recover: Restore from backup if needed
-
Configuration Tampering
- Detect: Monitor configuration events
- Respond: Revert changes, investigate
- Recover: Restore correct configuration
-
Exploit Attempt
- Detect: Monitor for unusual patterns
- Respond: Disable affected functions
- Recover: Patch and redeploy if needed
Response Procedures
- Immediate: Contain the threat
- Short-term: Investigate and document
- Long-term: Implement fixes and improvements
Compliance
Documentation Requirements
- Security architecture documentation
- Access control procedures
- Incident response procedures
- Audit logs and records
Regular Reviews
- Quarterly security reviews
- Annual comprehensive audits
- Post-incident reviews
- Configuration change reviews
Related Documentation
Last Updated: 2025-01-27