Quote:
Like making the calculator bootloader check the flashed firmware and display a splash-screen that tells if the calculator is running an official firmware or not. All you need to trust then is that the bootloader hasn't been tampered with and that the RESET button works.

The calculator already does this. The issue is, the calculator entirely refuses to boot if the OS isn't signed by TI, so that means that there are no developer options besides finding bugs in either the boot code or the OS. You also can't trust that the bootloader hasn't been tampered with (as you could always reflash the ROM chip, even though that's pretty difficult), not can you trust that the reset button works (you could wire it up to a particular key, then run a program that waits for that key and fakes a reset).

I've been considering how to make a calculator entirely secure. The best solution that I've come up with so far is to have a USB dongle (or a mobile app that uses NFC) that causes the calculator to enter test mode. To do this, it would send a unique ID for the dongle, test mode settings, and a randomly generated challenge to the calculator. The calculator would then sign the exact message that the dongle sent, plus some extra data about the OS signature and version, with a private key stored in the bootcode and return to the dongle. If the dongle doesn't receive a properly signed response from the calculator within a few seconds, or if the OS signature is incorrect or the OS version outdated, it plays an audible tone to indicate that the test mode entry failed.
If the OS version is incorrect, the dongle could also send an OS update to the calculator. After that completes, it would attempt to verify again.
To exit test mode, the same dongle has to send its ID back to the calculator. To prevent a situation where the dongle could be lost and the calculator stuck in test mode forever, test mode could also be exited by waiting for 24 hours.
This, of course, would be useless if the bootcode was readable, so the flash chip would have to be integrated into the same IC as the CPU, and settings would have to be configured so that only the bootcode can read the key. I'm by no means an electrical engineer, but if I understand correctly this would be fairly easy to do with an ASIC and is probably possible to do with something like an ESP32.
To lessen the impact if a key did manage to get out, each calculator could have its own unique private key, and the private key + serial number could be signed by the manufacturer's private key, which isn't distributed anywhere. That way, if a single calculator's bootcode was somehow read, that key could be marked as invalid through a software update to the test mode dongle/app.

This system would have a number of advantages over the current one:
It's basically impossible to fake a reset. If control isn't given to the bootcode when a test mode request arrives, the dongle will be able to tell and will alert the proctor. If control is given to the bootcode, the calculator will reset properly assuming no bugs in the bootcode.
Running native code outside of test mode or a custom OS version wouldn't compromise security. Since the bootcode verifies the OS, the test mode dongle would detect the custom OS and install a signed OS version only for test mode.
It's not possible to install a modified bootcode version and still enter test mode. Even if you entirely replaced the IC with your own, you would need to know the private key from an actual calculator to be able to enter test mode.
A teacher or exam institution could have fine-grained control over what functions are allowed. Since you don't have to enter test mode details using only physical buttons, the test mode could be set up to disable certain tokens or features without affecting the rest. For example, a high school teacher trying to teach algebra could disable graphing for a test to make sure that students were solving the problems algebraically rather than visually.
This would also allow the calculator to include functionality that current calculators don't due to cheating concerns. For example, it could include an exact math engine or even a CAS that could be disabled in the exam settings. School edition calculators could also include permanent test mode settings to disable this functionality outside of tests for things like homework assignments.
Finally, since program development isn't restricted outside of test mode, developers won't have a reason to try to find bugs that could potentially be used for cheating in order to run their own programs.


This still wouldn't prevent students from connecting the screen and keypad to a raspberry pi and leaving the old bootcode running, but if you're extremely paranoid about that you could probably just make the case out of clear plastic. Not only would it look super cool, it would also allow teachers to visually verify that there are no unauthorized hardware modifications inside.
I don't think a developer edition is a bad idea. The walled garden approach has worked for other app environments. If someone wants to make a native program they can use DE all they want, and then submit the program to TI for approval and signing for playing on other calculators. They just need to have someone make sure the community isn't making cheating software. I think it'd be a fair trade.

This probably does mean that anything edgy (word: emulators) may not make the cut and would be subject to corporate censorship. But that's the whole reason this mess exists in the first place anyway, it's a proprietary product.
geekboy1011 wrote:
My proposition would be more in line of what every other major end user device does at this point.
Implement some proper OS/Boot loader security. Give us a separate OS version for running ASM/C that when installed pops up a lovely boot loader based splash screen. You know like every major unlock-able cellphone out there now?
as well as implement some OS HASH checking in some form or another to test for in place modifications.
The real issue with these calculators is the lack of ingrained security, Moving to a Larger signing Key was a good, albeit slow, move. They needed to also implement some runtime checks with that. And lastly they need to shore up their boot page protections and this will be a quite secure handheld.


The main issue is that teachers don't want to actually learn how to make sure students aren't cheating, they just expect TI to make calculators cheater-proof without them having to do anything. No amount of possible security measures are going to do anything if teachers refuse to learn how they work. The most any teacher I've had has ever done is ask people to clear the RAM and quickly glance at the screen to check that it says it's been cleared, and a lot of teachers don't even do that much. None of these teachers have any idea about things you could find with a single Google search like test mode or archived programs, let alone understanding OS versions or integrity. No amount of security measures are going to fix the issue that it's stupidly easy to just make an assembly (or even TI-BASIC) program that will fool most teachers who don't know anything about security measures. The only thing that's really going to solve the problem is if TI makes more of an effort to inform teachers about what steps they need to take to ensure that students aren't cheating,
ContronThePanda wrote:
geekboy1011 wrote:
My proposition would be more in line of what every other major end user device does at this point.
Implement some proper OS/Boot loader security. Give us a separate OS version for running ASM/C that when installed pops up a lovely boot loader based splash screen. You know like every major unlock-able cellphone out there now?
as well as implement some OS HASH checking in some form or another to test for in place modifications.
The real issue with these calculators is the lack of ingrained security, Moving to a Larger signing Key was a good, albeit slow, move. They needed to also implement some runtime checks with that. And lastly they need to shore up their boot page protections and this will be a quite secure handheld.


The main issue is that teachers don't want to actually learn how to make sure students aren't cheating, they just expect TI to make calculators cheater-proof without them having to do anything. No amount of possible security measures are going to do anything if teachers refuse to learn how they work. The most any teacher I've had has ever done is ask people to clear the RAM and quickly glance at the screen to check that it says it's been cleared, and a lot of teachers don't even do that much. None of these teachers have any idea about things you could find with a single Google search like test mode or archived programs, let alone understanding OS versions or integrity. No amount of security measures are going to fix the issue that it's stupidly easy to just make an assembly (or even TI-BASIC) program that will fool most teachers who don't know anything about security measures. The only thing that's really going to solve the problem is if TI makes more of an effort to inform teachers about what steps they need to take to ensure that students aren't cheating,


You said it, not just the teachers but the testing boards as well, This is IMO not TI's problem its the test boards and the teachers problem. If they do not care then they are not doing their students/testees justice. It is the teachers and proctors jobs to ensure integrity, NOT TI.
TI making these changes just limits their product, Instead of putting the responsibility on the people who are supposed to actually care. Once again the ones of us who behave lose our privileges because of the one person who did not care.
ContronThePanda wrote:
The main issue is that teachers don't want to actually learn how to make sure students aren't cheating, they just expect TI to make calculators cheater-proof without them having to do anything. No amount of possible security measures are going to do anything if teachers refuse to learn how they work.
I think that hits the real issue on the nose. Ironically, a lot of teachers do not want to learn anything new. I suspect that attitude gets passed along to students and then they wonder why the students don't like their class.
TI tweeted about the OS update... They conveniently left out the part about not being able to run most programs amymore. I find it really slimey to try to dupe / deceive users into blindly updating by intentionally leaving out the most relevant information, even more so considering that they won't be able to downgrade.

Not to mention that the webpage for the TI-83 Premium CE Edition Python still lists ASM as a supported programming language, which might even be illegal.
I'm loving the comments below that. https://twitter.com/TIEducationFR/status/1264964591404101634
mr womp womp wrote:
Not to mention that the webpage for the TI-83 Premium CE Edition Python still lists ASM as a supported programming language, which might even be illegal.


Lawsuit time!
Texas Instruments wrote:
prioritize learning
Specifically, prioritize learning that education mustn't be fun.

Edit: Have some quotes from SAX discussing this:
commandblockguy wrote:
tbh I learned more math writing game engines than I ever did in an actual class
and when I finally did get to a math class that taught me something I didn't already learn on a personal project, it was super boring because it had zero context associated with it
and I'd assume that every math class is like that to the average person
KermMartian wrote:
A story I've heard repeated again and again.
Geekboy1011 wrote:
Even i can say that at this point
I've learned more math doing real world work then being force fed repetition in school
DrDnar wrote:
Linear algebra was so boring; it wouldn't be boring if it were called "Mathematics of Computer Graphics."


Edit 2: I'm still in a sardonic mood.
Texas Instruments wrote:
We welcome your feedback in improving Python.
The Community wrote:
Our feedback is that you sorely need our help in making this thing run anything other than C or assembly fast enough that students won't learn to hate programming.
I'll be summarizing these soon, but a few items of coverage I've seen around the internet:
After reading through a handful of these, I noticed that most of them mention that it prevents "casual cheaters" but won't stop "determined cheaters". That's simply not the case. The most common form of cheating by far is people just entering their class notes and equations as programs and reading through it during an exam since teachers don't use exam mode. A common thing for examiners to do is ask that students reset their RAM, which can be easily dodged by slightly more savvy students. The update does absolutely nothing to try to prevent this type of cheating. In terms of preventing cheating, the update really only prevents some obscure edge case that hasn't been observed out in the wild.
Personally I think we were all expecting this to happen eventually. I think the reason the Python chip is so underwhelming is - pretty much the only thing TI truly cares about - teachers. In TI's eyes, less power apparently equals more security? I was appalled once I finally learned how bad TI Python truly is in terms of potential. I'm sure they're only adding it to appeal to the STEM obsessed schools nowadays. During my time in school, I never once had a teacher willing to utilize the programming potential of an 83. Hell, it amazes me how much time we would've saved not going on and on about memorizing formulas when literally 3 minutes of time would've completely removed that stress for the other kids.

Ultimately, this is just another example of how out of touch they are with us (and schools, more on that in a bit). The chance of a modern high school student even having the smallest knowledge on EZ80 assembly is about the same as a 90 year old man attempting to install an Android APK and succeeding.

Casio and Hewlett-Packard have shown that they've been able to seriously compete with TI in terms of features for several years now. And when TI eventually does try to adapt, they end up releasing a buggy mess that's about as stable as Minecraft with 30 mods installed (ex. 84 PCSE).

With more on the topic of these even becoming obsolete for schools; many students and teachers from my later HS years were actually beginning to complain about things like the dreadfully slow graphing, a screen they can't even read clearly, and batteries that tend to rust in a classroom environment. Did I forget to mention the almost Beta stage-like emulator they released? Oh boy.

Ultimately, it's not going to be long before TI's empire starts forming cracks considering the way they're doing business right now. In terms of a future leader in the industry, I'm placing my bets on Casio. They've already dominated pretty much every other continent besides North America.

In terms of a solution: it's probably not going to get passed the concept stage. An OS for developers would be nice, but God knows how much a license for it would cost.
Rawto wrote:
Ultimately, it's not going to be long before TI's empire starts forming cracks considering the way they're doing business right now. In terms of a future leader in the industry, I'm placing my bets on Casio. They've already dominated pretty much every other continent besides North America.


I don't know about the rest of the world, but Texas Instruments certainly doesn't have a monopoly here in France. Casio and TI used to have roughly the same market share for the longest time, but the available data points on TI-Planet predate the NumWorks calculator's introduction so it's anybody's guess now.
Looks like I won't be upgrading my OS.
boricj wrote:
Rawto wrote:
Ultimately, it's not going to be long before TI's empire starts forming cracks considering the way they're doing business right now. In terms of a future leader in the industry, I'm placing my bets on Casio. They've already dominated pretty much every other continent besides North America.


I don't know about the rest of the world, but Texas Instruments certainly doesn't have a monopoly here in France. Casio and TI used to have roughly the same market share for the longest time, but the available data points on TI-Planet predate the NumWorks calculator's introduction so it's anybody's guess now.


At least from my experience the only reason Casio still holds on in places is price. And I'm not surprised the Casio UI is much worse than TI's and the feel of the keyboard and just general hardware quality is nowhere near the same. TI just makes better kit from what I've seen and since HP doesn't seem to care about the education market their superior feeling and more durable calculators don't really matter in this context.

As for the NumWorks, I'll have to feel one in my hand to say for sure but based on the pictures it looks like a toy though so do the original TI-84/Pocket/SE. I just hope the keypad is at least on par with TI's rubber domes as whatever Casio did on the Prizm and similar calcs make them so mushy I can't stand to use them for more than a few minutes and hope NumWorks did better.
TheStorm wrote:
TI just makes better kit from what I've seen
Indeed, I think people don't give TI enough credit for the quality of their hardware. Yes, the specs are terribly dated, but the hardware is genuinely durable. In fact, I would argue that the two greatest features of the B&W TI-83 Plus line and successors aren't even noticed by most students: their excellent durability and awesome battery life. In fact, I suspect their engineers think a rechargeable TI-84+ would be silly. The battery's own self-discharge would affect battery life as much as actual usage.
Tech Spot recently posted one of the most accurate articles covering this situation that I've seen so far. They did a really good job covering information from various forums like Cemetech, TI Planet, Planet Casio, and LTT.
https://apple.news/AZ1Z2KTq5Q96Q6MQ-jgBTDw
TheLastMillennial wrote:
Tech Spot recently posted one of the most accurate articles covering this situation that I've seen so far. They did a really good job covering information from various forums like Cemetech, TI Planet, Planet Casio, and LTT.
https://apple.news/AZ1Z2KTq5Q96Q6MQ-jgBTDw
That is indeed a great article, thanks. I've added TechSpot's own link to the URL list above.
Please tell me; how are we supposed to create great Python games for the CE, when we don't even have a getKey() function ?

The sys module only includes a waitKey() function, which is not suitable for an Oiram CE Python Edition and many other games.
We are clearly not supposed to create games. The CE is (officially, I mean ^^) set to become closer to what the Nspire has always been: a consumption platform, instead of a production platform. Needless to say, that's not the way to let students interested in programming. Meanwhile, Western countries keep lamenting that they can't fulfill demand for qualified STEM jobs...
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 3 of 5
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement