search

NimRo97 / pv204_in_dr

Repository for PV204 course semestral project @ Faculty of Informatics, Masaryk University
MIT License
1 stars 0 forks source link

Is OOP automata-based programming used? #33

Closed mvondracek closed 4 years ago

mvondracek commented 4 years ago

Hello all, your project caught my attention during final presentations, and I really like the work you guys did. I checked the presentation and report again because I was interested in some project which utilized automata-based programming for java cards. Your presentation seems like you implemented this approach. However, I cannot find OOP automata-based source code in your applet. I found the statusVar attribute, which can have a value of 0, 15, or 240. Is your FSM implemented with assigning and checking values of this attribute, or are there anywhere defined states with transitions and allowed actions? Thanks!

NimRo97 commented 4 years ago

Hello, in the code itself, it is only done by checking the values in variables and allowing the execution if and only if the correct "state" indicated by the contents of the variables is in place. The automata-based approach was used only when deciding what the program flow should be, i.e. on paper before we programmed it. We did not program the states using complex OOP programming structures because a) it would cause additional overhead on a real card and b) it would take too much time (we lacked one team member). I, too, am struggling to find nice examples of real application developed using automata-based programming techniques employing objects. I don't believe it is usually done on real Java Card applets, because if you have the execution flow distributed across several Objects with their states, it would slow the execution and the overhead would also cause some unnecessary EEPROM wear-down. I guess rewriting the code to use methods and variables to represent the transitions/states and doing formal verification of code keeping the security properties would be a better approach for embedded hardware.

mvondracek commented 4 years ago

Extensive writes to EEPROM are definitely a valid concern. I wonder how significant is the performance trade-off for structuring code into more classes. I would love to see applets with better class models, but the question is whether we can afford it in the java card environment. Anyway, thanks for a quick reply.