Design Phase Flags

Scenario

ChipCorp Inc. is the world’s largest chip manufacturing entity. [1] Their products are in everything from children’s toys to water treatment equipment for critical infrastructure. To maintain their competitive advantage and to protect their customers from a supply-chain attack, they are in the process of creating a new secure file storage and transfer system to ensure their proprietary fabrication data does not fall into the wrong hands, prevent unauthorized modification of key files, and protect their fabrication infrastructure from tampering.

ChipCorp has contracted your team to help design, create, and test an embedded security subcomponent of the larger system, a permissioned hardware security module (HSM). The HSM will have a Management Interface, over which a user can list, read, and write files. It will also have a Transfer Interface, over which two HSMs can transfer files.

The HSM you design will need to communicate with other pieces of a larger system, so it is an absolute necessity that you stick with the Functional Requirements laid out by ChipCorp. They have also provided a set of Security Requirements that you should seek to have your design adhere as closely as possible to. They recognize that budgets and timelines are not infinite, and they are willing to accept tradeoffs in order to receive a completed design on time. However, security is what you were contracted for, so the more secure your system, the better.

Flags

During the Design Phase, teams can show that they are staying on track and earn some points by submitting Design Phase Flags. Teams will earn full points for submitting flags by the deadline. Flags submitted after the deadline will earn half points.

Milestone	Flag Format	Due Date	Points	Description
Read Rules	ectf{readtherules_*}	January 21	100	If you read all the rules, you’ll know
Boot Reference Design	ectf{boot_*}	January 23	100	Provision and boot the Reference Design to receive a flag
Design Document	ectf{designdoc_*}	January 30	100	Submit an initial Design Document to your team channel
Debugger	ectf{debugger_*}	February 6	100	Show that you can use a debugger.
Use the Testing Service	ectf{testing_*}	February 13	100	Successfully complete a clone_repo flow on the testing service and read the results.
Attack the Reference Design	See: Attack Phase Flags	February 20	100	Capture flags by attacking a deployment of the Reference Design. In order to capture these flags you will need the reference attack package which can be downlaoded here: attack_package.enc. See List and Download Attack Packages for more details.
Final Design Submission	ectf{handoff_*}	April 15	1,000	Pass Handoff to earn points and enter the Attack Phase
Bug Bounty		April 15	Up to 200	See Bug Bounty below

Bug Bounty

If your team happens to find a bug in the Reference Design, you can earn points for it! Your team will receive 100 points for each bug found, and another 100 points if you submit a corresponding fix. If multiple teams find the same bug, points will be distributed on a first come, first serve basis.

Sometimes whether an issue is truly a bug (or a feature!) is a matter of opinion - the eCTF organizers reserve the right to reject bug reports for trivial issues and combine multiple similar reported bugs into one. Submitted bugs will be accepted if there is a violation of the functional requirements in the reference design that prevents it from working correctly under nominal operation.

Submissions for typos or clarifications on documentation provided by the organizers will not be considered for additional points, although we appreciate being notified about these mistakes so we can make the appropriate edits and provide further explanation where it is necessary.

Please submit Bug Bounty requests through your private team channel on Zulip tagging @organizers.

[1]

The scenario presented here is purely fictional and although it parallels real-world situations, it does not perfectly reflect reality. Any similarity to real entities or events is purely coincidental.